Replace PVsyst and Proposal Software: Workflow Guide

Replacing PVsyst is not a software-shopping exercise. It is a controlled change to the way an EPC turns site data into an engineering result, a financial case, and a document the customer can approve.

The decision becomes harder when PVsyst is only one part of the current process. Many teams simulate in PVsyst, transfer results into a spreadsheet, and build the proposal in Word, PowerPoint, or another sales platform. A replacement must remove those handoffs without weakening technical review.

This guide shows how to test that change. It also explains when keeping PVsyst is the better engineering decision.

In this guide:

• Decide whether one platform can cover your actual project classes
• Find the handoffs that create duplicate entry and version risk
• Define engineering and sales acceptance criteria
• Compare a disconnected stack with a consolidated workflow
• Run a 6-step validation on representative projects
• Calculate total workflow cost using your own operating data
• Identify cases where PVsyst should stay in the process

Can One Platform Replace PVsyst and Proposal Software?

A candidate may replace defined parts of a PVsyst-to-proposal process when the technical, commercial and governance owners approve its tested scope. This guide does not establish that any named platform reproduces every PVsyst method or deliverable. The team should keep PVsyst wherever a contract, lender, independent engineer, or unsupported advanced study requires a PVsyst deliverable.

That answer has 2 parts. First, a platform must perform the work. Second, the people who approve that work must accept the evidence it produces.

A feature checklist only tests the first part. A product page may mention shading, yield simulation, or financial modeling, yet that does not prove that it supports your weather source, loss structure, tariff case, proposal fields, or review procedure.

The replacement decision should therefore start with 3 gates:

SurgePV publishes this guide and sells solar software. Its design product page describes roof modeling and module layout. Treat these as vendor-reported capabilities and require a demonstration against your own requirements. No independent hands-on equivalence benchmark is retained for this article.

PVsyst 8 covers grid-connected, standalone, and pumping systems. Its official product page also lists bifacial systems, trackers, sub-hourly simulation, ageing analysis, batch processing, loss analysis, economic assessment, and detailed reports. Teams using those methods should map them one by one before considering retirement of the existing license.

The practical goal is not “replace PVsyst at all costs.” The goal is to reduce unnecessary work while protecting the technical basis of every offer. Sometimes the right outcome is full consolidation. Sometimes it is a hybrid process in which early design and proposals move to one cloud platform while final technical studies remain in PVsyst.

Why the PVsyst-to-Proposal Handoff Breaks

PVsyst describes its software as a PC application for PV system study, sizing, and data analysis. It can produce a detailed engineering report and run an economic evaluation. That is different from managing the complete path to a branded, customer-facing proposal.

One Project Becomes Several Versions

A disconnected workflow often creates a chain like this:

1. A designer develops the array and electrical concept.
2. An engineer configures the simulation in PVsyst.
3. Selected results move into a spreadsheet or financial model.
4. A sales or bid team copies those results into a proposal template.
5. The customer requests a different module, price, tariff, or layout.
6. Each owner updates their own file and passes the change onward.

PVsyst supports copying tables and exporting table data as CSV text, according to its official beginner documentation. Export is useful, but it creates a new object outside the source model. Unless a separately verified integration maintains the relationship, the receiving document needs its own source-revision control.

A proposal may therefore contain annual production from simulation revision C, a layout image from revision D, and a price based on a different module count. That example is a failure mode, not a claim that every multi-tool team makes this mistake.

The core issue is data lineage: the ability to show where a proposal value came from, which assumptions produced it, and whether it remains current. More handoffs mean more points where lineage can become unclear.

Revision Risk Grows After Every Export

Consider a customer who asks for a module substitution after the first commercial review. The change may alter module count, DC capacity, inverter loading, string configuration, BOM, annual yield, project price, payback, and the proposal narrative.

In a disconnected stack, the team must first identify every downstream file. Then each owner has to recalculate or replace the affected values. A clean checklist can control this process, but the work still exists.

The problem is especially visible when the proposal is treated as a designed PDF rather than an output of the project record. A polished cover page can hide stale engineering values. Reviewers then spend time comparing documents instead of examining the design decision.

A consolidated workflow aims to reduce manual transfers; test which handoffs it actually removes. It does not remove the need for engineering judgment, approved assumptions, or document review. A candidate may keep related values in one workspace; the team still owns the decision to issue them.

This is why “Does the tool simulate?” is the wrong buying question. A better question is: “When a design input changes, which technical, financial, and client outputs update from the same approved project record?”

What the Replacement Workflow Must Cover

A serious evaluation begins with requirements, not a demo script. Write down the outputs your company sells, the project conditions it encounters, and the people who must approve each stage.

PVsyst’s published capability set provides one boundary. Your internal templates, commercial models, and client terms provide the other. The replacement must work between them.

Engineering Acceptance Criteria

The technical test should cover input fidelity before output similarity. Two annual-yield numbers can look close for the wrong reasons if weather data, horizon, albedo, soiling, thermal behavior, or availability assumptions differ.

Record at least these fields for each test project:

For each candidate, test the supported geometry, electrical configuration and shading method. A feature label such as “shading” does not prove the same irradiance, mismatch or module/string model as PVsyst. Document methods that cannot be aligned and retain an approved specialist route.

Sales and Proposal Acceptance Criteria

The commercial test begins where the engineering report ends. Decide which values the customer sees, who approves them, and how revisions reach the final document.

A proposal acceptance list commonly includes:

• Customer and site details
• Approved array visuals and equipment schedule
• System size and expected production
• Financial assumptions, price, and payment structure
• Payback, IRR, or NPV where applicable
• Disclaimers and proposal validity
• Brand elements and contact details
• Revision identifier and approval status

PVsyst’s economic evaluation can calculate LCOE and long-term profitability using installation costs, operating costs, financing parameters, and tariffs. That can inform a commercial case, but the EPC must decide whether its customer proposal uses the same inputs and definitions.

SurgePV’s financial product page describes IRR, NPV and payback calculations. Its proposal page describes branded web and PDF output. These vendor descriptions identify what to test; they do not prove model parity, tariff fit or automatic acceptance. Trace the displayed figures to the exact inputs and revision used.

The last requirement is honest omission. If the candidate platform cannot represent a required tariff, contract structure, risk case, or technical method, record that gap. Do not bury it inside a broad score.

Current Stack vs Consolidated Workflow

Workflow consolidation changes the project record more than it changes the engineering sequence. A site still needs valid inputs. An array still needs design review, and a financial model still needs approved assumptions.

What changes is the path between those decisions and the customer document.

Check the candidate’s deployment, account controls, exports and retention before moving active work. Ask vendors to demonstrate required integrations and automation. This guide does not certify a native CRM, proposal API, field app or AI approval capability. The named engineer and commercial owner remain responsible for issued outputs.

For some teams, consolidation removes the proposal application but retains PVsyst. For others, it can replace both for defined rooftop project classes. The evaluation matrix should permit either outcome rather than forcing a single company-wide answer.

How to Validate a PVsyst Replacement in 6 Steps

A parallel run is one practical way to separate a persuasive demonstration from a repeatable production process. Define the test before the candidate vendor sees the projects, then require evidence for every acceptance rule.

1. Choose a Representative Project Set

Do not choose only the cleanest roof in the archive. Select projects that represent the work the team actually sells.

The set may include a simple pitched roof, a multi-obstruction commercial rooftop, a flat roof with several orientations, and a project with a difficult tariff or revision history. If ground-mount, bifacial, tracker, storage, or sub-hourly studies matter, include them as separate classes.

Use completed projects when possible. They already have approved inputs, issued documents, and known review questions. Remove customer-identifying data if the test environment or vendor process requires it.

2. Freeze Inputs Before Comparing Outputs

Create a test manifest for every project. Freeze the coordinates, weather basis, equipment, geometry, string configuration, loss assumptions, financial inputs, and proposal terms.

The rule is simple: the same input should mean the same thing in both systems. If one tool uses a different default, record and reconcile that difference before comparing results.

Do not start by demanding an arbitrary annual-yield match. Start by comparing the model structure. A difference caused by a named weather source is more useful than an identical total produced by offsetting assumptions.

3. Rebuild the Projects in the Candidate Platform

Ask the people who would use the software to perform the rebuild. A vendor-led demonstration proves that the vendor can operate its product. It does not prove that your team can repeat the workflow under normal deadlines.

Record each manual workaround, missing database item, interpretation question, and approval step. Also record which exports or external applications remain necessary.

Where SurgePV is the candidate, request a requirements demonstration covering the specific route and deliverables in scope. The purpose is to see whether one project record survives the full route.

4. Investigate Differences Instead of Averaging Them Away

Compare outputs at a useful level. Annual energy alone can hide a seasonal difference, while a performance ratio alone can hide different loss assumptions.

Build a reconciliation log with these columns:

Set tolerances by project class and output. A lender-facing yield result may need a different rule from an early-stage sales estimate. The acceptance value must come from the EPC’s risk policy, contract, or reviewer, not from this article.

5. Test the Client-Facing Output

Generate the proposal from the tested project. Compare its figures with the approved technical and financial records.

Then create a realistic revision: swap the module, change the price, alter the electricity tariff, or remove an array area. Confirm which fields update, which require review, and which remain static copy.

Sales should review readability and customer fit. Engineering should verify technical claims. Finance should approve the commercial definitions. No single department can accept the whole workflow alone.

6. Run Both Workflows in Parallel

Move from historical tests to controlled live work. Run both processes on a small set of current projects without retiring the old route.

Track coverage rather than days. The parallel run should include normal design, at least one material revision, financial approval, proposal issue, and technical sign-off for every project class in scope.

Use this acceptance record:

The retirement decision comes after this record is complete. A failed test is useful: it tells the team which project class needs a hybrid workflow or a different candidate.

Worked Example: A 500 kW Commercial Rooftop

The following scenario is illustrative. Its values are not measured results, customer data, or a claim about software performance.

An EPC prepares a 500 kW rooftop offer. The current process uses one design file, PVsyst for yield, a spreadsheet for project economics, and a document template for the proposal.

The first issue package contains these example inputs:

The customer then requests a different module. The new model has a higher nameplate rating but different dimensions and electrical characteristics.

In the disconnected workflow, the designer checks whether the new module fits the roof and revises the count. The engineer updates the PVsyst component and array configuration. The commercial analyst replaces the production and system-size values in the financial model, while the proposal owner changes the equipment table, graphics, and output figures.

The review question is not merely whether the PDF says “new module.” The reviewer must trace the change through:

1. Roof fit and module quantity
2. DC capacity
3. String length and inverter input allocation
4. BOM
5. Shading geometry
6. Energy result
7. Financial outputs
8. Proposal tables and visuals

Test whether the candidate updates these values from the approved revision. Record manual steps that remain. Consolidation has not been demonstrated if the team must silently repair stale proposal values after the change.

Suppose the new module produces an illustrative revision B design of 495 kW rather than 500 kW. The team should not force the proposal to preserve the old headline size. It should reissue the system size, module quantity, production estimate, price basis, and financial result from revision B.

The most revealing test is a redline exercise. Ask each reviewer to mark the source of every changed proposal field. If a value cannot be traced to the revised project or an approved commercial input, the workflow has failed even if the document looks correct.

This example also exposes a limit. If the project requires a final PVsyst file for an independent engineer, the consolidated platform may own design, pricing, and proposal stages while the approved PVsyst model remains the final yield artifact. That is a valid hybrid design, provided the proposal identifies the accepted yield revision.

Calculate the Business Case Without Invented Savings

The official PVsyst shop lists PVsyst 8 Professional at CHF 700 per year, checked September 30, 2026. Obtain current quotes and include the licences that remain necessary in a hybrid workflow. Current trial documentation describes a 30-day evaluation with generic components and labelled reports; do not assume unrestricted equipment-specific testing.

Do not use a vendor’s general time-saving percentage in the approval model. Measure a representative project under both workflows.

TCO Worksheet

Use the following annual cost model:

First-year workflow cost = all retained and candidate licences + implementation + training + operating labor + support and administration

Populate this table with your own records:

Calculate labor cost as:

Annual labor cost = projects per year × loaded hourly rate × (base hours per project + hours per revision × revisions per project)

Separate first-year implementation and training from recurring operating costs. Count a licence or labor task once: retained tools belong in total licences, and support/admin hours should not also be counted as project labor. This is a planning formula, not an accounting standard. Include local payroll burden and overhead only if your company uses them consistently in other investment decisions.

Capacity and Revision Cost

The second calculation is capacity. If a design team removes manual transfers, it may finish more qualified work without adding staff. That value is only real when demand and downstream capacity exist.

Use:

Annual hours released = projects per year × measured hours removed per project

Then decide how those hours will be used. Possible uses include more bid responses, faster revisions, technical QA, or fewer outsourced tasks. Do not convert all released hours into revenue unless the sales pipeline can supply additional projects and installation operations can deliver them.

Revision cost deserves its own line because it often exposes the handoff penalty. Measure a module substitution, a tariff update, and a layout change. Count active work time across design, engineering, commercial review, and document production.

The final business case should show 3 scenarios: full replacement, hybrid retention of PVsyst for named project classes, and no change. A hybrid case often gives the most credible comparison because it includes the cost of specialist software that remains necessary.

When You Should Keep PVsyst

PVsyst remains a strong specialist simulation product. Replacing a disconnected workflow does not require denying that strength.

Keep PVsyst for a project when the counterparty specifies it. A lender, independent engineer, investor, owner, tender, or contract may require a PVsyst report or source file. Substitute output should not be presented as equivalent without that party’s written acceptance.

The same caution applies to advanced studies. PVsyst 8’s official feature list includes bifacial systems, trackers, sub-hourly simulation, ageing analysis, batch processing, standalone systems, and pumping projects. If your team relies on one of these functions, verify the complete method and output before moving that project class.

Legacy projects provide another reason to retain the tool. A historical PVsyst archive contains the model that supported an earlier offer, financing review, performance guarantee, or operating analysis. Keep the original files, software-version notes, weather source, component definitions, and issued reports according to company policy.

PVsyst’s release notes also show why version records matter. Version 8.1.2, published on 6 May 2026, included corrections touching battery energy balance, economic evaluation behavior, Meteonorm horizon handling, and an optimizer/string-power issue. That does not mean earlier work is invalid; it means reproducibility depends on knowing which version and settings produced a result.

A hybrid workflow can be explicit:

This model prevents a specialist exception from forcing every project through the same handoffs. It also stops a fast preliminary tool from being used beyond its approved scope.

The best replacement policy is therefore conditional. Define the projects that can move, the projects that cannot, and the evidence needed to change either list.

A Practical Migration Checklist

A successful migration is a governed release, not a license cancellation date. Use this checklist to control the move.

Before the Parallel Run

• Name a technical owner, commercial owner, and operations owner
• List every project class and required deliverable
• Record current tools, templates, licenses, integrations, and exports
• Select representative historical projects
• Freeze test inputs and acceptance rules
• Preserve original PVsyst files and issued customer documents
• Confirm the candidate’s export, access, and retention options

During Validation

• Rebuild each test project from the frozen manifest
• Reconcile weather, geometry, equipment, electrical design, losses, and yield
• Verify financial definitions and tariff assumptions
• Generate the branded proposal from the same project
• Run at least one material revision
• Record workarounds, gaps, and retained tools
• Assign each difference to an owner and final decision

Before Retirement

• Complete live parallel projects across every in-scope class
• Approve templates, naming conventions, permissions, and QA gates
• Train designers, engineers, sales staff, and reviewers by role
• Document exception routing back to PVsyst
• Export records required by the archive policy
• Set a rollback point and support owner
• Cancel a license only after its projects and records are accounted for

Data migration should be selective. Moving a weak template into a new system reproduces the old problem. Preserve source records, but rebuild approved templates and assumptions deliberately.

Do not promise automatic file conversion unless the candidate provides and tests it. A practical migration may preserve PVsyst projects as an archive while recreating only active projects and approved starting templates in the new platform.

The final artifact should be a short operating procedure. It should state who can start a project, who approves technical inputs, who approves financial assumptions, which projects require PVsyst, what the proposal revision means, and how issued files are retained.

Make the Retirement Decision

The decision to replace PVsyst and proposal software should be made at workflow level. A lower license count is useful, but it does not prove that the new process is safer, faster, or suitable for the projects your EPC sells.

Start with 3 actions:

1. Map the handoffs. Identify every place where geometry, energy, cost, or proposal data is copied between files.
2. Run the 6-step test. Freeze inputs, rebuild representative projects, reconcile differences, test revisions, and complete live parallel work.
3. Approve a conditional operating model. Move only the project classes that pass, and retain PVsyst for named technical or counterparty requirements.

SurgePV is one candidate to evaluate against the documented project and proposal requirements. The right proof is not a generic product tour. It is one of your real projects, rebuilt against your own acceptance matrix.

If that test passes, the team can remove handoffs with evidence. If it fails for one project class, keep the specialist route and consolidate the rest.

Use a requirements demo to test the complete path from project input to revised customer proposal. Bring the PVsyst report, proposal template, and exception list so the evaluation reflects production work.

For product scope, use the PVsyst review. For final-study evidence, see the PVsyst report review guide. If you retain external simulation support, use the simulation services procurement guide to define deliverables and revisions.

Frequently Asked Questions

Can SurgePV replace PVsyst?

Evaluate SurgePV against the required project inputs, methods, outputs and review conditions. This guide establishes no universal simulation equivalence. Keep PVsyst for named deliverables or specialist methods not covered by the accepted candidate workflow.

Does PVsyst create solar sales proposals?

PVsyst documents engineering reports and economic evaluation. Define the branded customer document separately and test its required fields, commercial terms, visuals and revision control. Do not assume that either report format automatically satisfies your sales process.

How do you validate a PVsyst replacement?

Choose representative projects, freeze inputs, rebuild in the candidate, reconcile methods and outputs, test a material revision and complete controlled parallel work. Agree acceptance rules before testing and record unsupported steps.

Should commercial EPCs keep PVsyst?

Keep it where a counterparty requires its files or reports, where approved specialist methods remain necessary, or where legacy work needs reproduction. A complementary design or proposal workflow can be evaluated without cancelling the simulation route.

What project data must be migrated from PVsyst?

Preserve site/weather references, equipment, geometry, electrical configuration, loss assumptions, results, economic inputs, reports and version records. Recreate active work selectively and test any vendor-supported conversion before relying on it.

How long should a parallel software run last?

Use project-class coverage and completed revision/review evidence rather than a universal number of days. Retire a route only after acceptance, archive access, exception handling and rollback responsibilities are documented.

Sources

• PVsyst 8 official product page: supported simulation functions
• Official PVsyst shop: public annual licence price
• PVsyst licensing documentation: current restricted evaluation
• PVsyst documentation overview: product scope, system study, sizing, data analysis, and reports
• PVsyst economic evaluation documentation: LCOE and profitability inputs
• PVsyst tips for beginners: table copy and CSV-text export
• PVsyst release notes: version 8.1.2 publication date and listed corrections

Sources checked September 30, 2026. Published by SurgePV. Product descriptions are vendor-reported; no independent accuracy, productivity or financing benchmark is claimed.