Consolidate a Solar Software Stack: Field and Interface Map

A software stack can look simpler while its project records become harder to trust. Before moving a function, identify who owns each material field and how a revision reaches the people relying on it. The immediate output should be a usable field-and-interface map, not a target number of subscriptions.

Scope and method

SurgePV publishes this desk-research guide and sells solar software. References were checked on September 30, 2026. No measured time saving, legal compliance or vendor integration is established by this framework.

This page narrows the stack question to project-data ownership and interface design. The tool-consolidation evaluation checklist owns the broader retain/connect/retire/defer decision. The replacement plan and migration guide own controlled transition and cutover. Do not retire or migrate a live system merely because the map below is complete.

Inventory decisions, not just subscriptions

Keep the original guide’s useful sequence: qualify, model, price, propose, procure, permit and hand off. For each decision, record the source input, responsible person, current system, receiving user and relied-on output.

A CRM may hold customer history; a design application may hold geometry; accounting may hold booked transactions. Actual ownership must be assigned by your company. A single application can contain several functions with different authorities.

NASA’s interface-management guidance provides a useful general analogy for defining boundaries and responsibilities. It does not certify a solar company’s software integration. The UK Technology Code of Practice similarly offers technology and interoperability context, not a local legal rule for every installer.

Build the material-field worksheet

Fill in actual systems and people. An empty authority field is an unresolved decision, not permission for whichever tool receives the data to overwrite it.

Distinguish transfer from validation

An integration may move a value correctly without making that value correct. Keep input status and review requirements alongside the data. A preliminary roof model or conditional incentive must not become an approved fact simply because it appears in the next application.

Vendor examples illustrate why mapping matters. Aurora’s project API documentation describes a project with customer, site and energy information and multiple designs. That does not mean another tool’s “project” object has identical fields or relationships. OpenSolar’s CRM page describes project management and connection possibilities; it does not prove your purchased connector works.

For each proposed interface, write:

• Source and destination objects and stable identifiers.
• Field meaning, units, required values and authoritative editor.
• Allowed update direction and material review triggers.
• Version/timestamp treatment and conflict policy.
• Permissions, credential owner and actual plan limits.
• Failure visibility, retry ownership and reconciliation method.

Bidirectional sync is not automatically desirable. A sales user should not silently overwrite an approved electrical configuration through a reverse update.

Trace one revision through the stack

Use a controlled representative project and change one material input—for example, the module model. Follow the change into quantities, electrical configuration, production, price and proposal. Identify which outputs update, which are flagged and which remain stale.

Then test a missing field, duplicate project, revoked access and failed transfer. Record expected and observed behaviour with the exact products, versions, configuration and roles. A successful normal transfer is not proof of recovery or complete history.

Do not perform these experiments on customer commitments without the responsible owner and appropriate safeguards. Matching outputs are not engineering approval, a permit or permission to operate.

Preserve historical access deliberately

Identify where prior designs, sent proposals, accepted terms, customer communications and field records remain accessible. Verify exports with attachments and relationships, not just a contacts spreadsheet.

A practical retrieval test is to reconstruct one representative project outside the originating account. Can the receiving person identify the active design, superseded proposal, accepted scope and open conditions without guessing? If not, improve retrieval before proposing retirement.

Retention, privacy and deletion requirements depend on records, contracts and jurisdiction. Assign those decisions to the appropriate owner. This page supplies a worksheet, not a universal retention period or authorization to remove data.

Close the map with an explicit decision

For every unresolved boundary, keep the owner, evidence needed and next action. Distinguish a tested route from a proposed connection and a deferred change. Record specialist systems and qualified review that must remain.

Bring this map to the software evaluation guide and any SurgePV demonstration. Ask for the actual design-to-proposal scope and supported handoffs. This guide does not establish that SurgePV replaces CRM, accounting, construction, procurement, monitoring or records systems, or that any particular interface is native.

Frequently Asked Questions

What should a solar software-stack map contain?

Record each material field or object, its authoritative source, current editor, receiving user, allowed transfer direction, revision identifier and error owner. Keep preliminary status and review requirements visible. A list of subscriptions alone does not explain the project-data dependencies.

Does a working integration validate the transferred design?

No. It can transfer an incorrect input faithfully. Preserve the source, status, units and review requirements, and test revisions, conflicts and failures. Qualified technical or commercial decisions do not become approved merely because their values appear in another application.

Can I retire a system once its fields are mapped?

No. The map informs a separate consolidation decision and transition plan. Test actual functions, usable exports, history, recovery and owner obligations before any retirement. This guide does not authorize migration, deletion or a universal records-retention period.

Can SurgePV replace the whole business software stack?

That capability is not established here. Verify the actual design-to-proposal scope and supported handoffs, and retain the appropriate CRM, accounting, procurement, construction, monitoring, records and specialist review systems for work outside that scope.