What a SolarNexus export really contains, how its jobs, participants, milestones and attributes map onto Payaca, and how we sequenced a live migration so crews kept working and no homeowner got a stray email.
This guide is for a solar install business that has decided to leave SolarNexus and wants to know what the move really involves. It's written from a migration we ran ourselves, end to end, on a business with several thousand jobs, a heat pump line and a service book. Everything below is what we found in the data, not what a brochure says should be there.
The short version: a SolarNexus export is rich and well structured, and almost all of it has a home in Payaca. The work isn't moving the records. It's deciding where each job sits on day one, keeping your automations from messaging homeowners while thousands of projects arrive, and bringing documents across in the order your team needs them.
Want us to look at your setup?
Book a walkthrough and we'll map your SolarNexus processes, milestones and attributes onto a Payaca workspace before you commit to anything.
We worked from the customer's own data export, delivered as a shared drive folder. It had two layers.
A job index. One CSV row per job across the whole database: job id, number, status and type. This is the census. Every check you run later reconciles against it.
One folder per job. Each folder held:
job.json, the full job record. That covers the job process and lead source, the sales owner, the participants (people and organizations, with contacts, mailing address and roles), the site address with coordinates, milestone phases, tasks, solutions and attributes.job_log.json, the job's activity log.index_documents.csv, a list of every document on the job with its SolarNexus tags (Proposals, Contracts, City Permit, Commissioning, Site Visit, Roof Areas and so on).A few things about the shape are worth knowing before you plan.
Attributes are wide. Our customer's account had over 200 attribute keys per job, covering sales qualification, site and roof details, electrical runs, permitting, service diagnostics and rebate tracking. On a typical job only around 30 were filled in. Years of custom fields pile up, and plenty of them were labeled "blank" or "note".
Solutions are full sales records. Each solution carries its price, financing option, first-year and lifetime production, offset and self-consumption figures, and the services and items in it. There were close to 6,000 of them across the book.
Documents are big. Around 157,000 documents were listed across 4,700 jobs, more than 100 GB in total, most of it site photos.
Later exports were deltas. The index was always the whole database, but the job folders only held what had changed since the previous export. Your verification needs to account for that, or you'll think jobs have gone missing.
Some things weren't in the export at all. Payments weren't there. Of roughly 32,000 tasks, only a few dozen carried an appointment time, so upcoming site visits had to come from a separate list the customer sent us.
The model, side by side
In SolarNexus, a job has participants and a site. In Payaca, a Customer is the person or company, with Customer Contacts and Addresses under it, and a Project is the job, linked to that customer. The first participant on a job became the customer, further participants became extra contacts, and the site became the project's site address. A repeat customer with three jobs ends up as one customer with three projects.
The rest mapped like this:
Nexus tag, and had a migration fieldset with the original id, status, type and process. Payaca's own numbering started above the highest SolarNexus number so the two can never clash.The rebuild column is mostly the workflow, and that's the point of moving. We built the customer's pipelines, stage guards, task templates and automations in Payaca before any data arrived, then placed each job into that new shape. You aren't copying SolarNexus. You're moving your book into a setup designed for how you want to run installs from now on.
A mirror test account first. Every load ran against a test account before it touched the live one. Before each rehearsal we copied the live account's setup across (tags, email templates, fieldsets, pipelines, stages, task templates, guards and automations) and checked the two matched exactly. On the test account every customer email and phone number was replaced or blanked, so nothing could reach a real homeowner whatever was switched on.
A small, hostile pilot. The first load was under 40 jobs, chosen to be awkward: duplicates, jobs with no email or no start date, every status and the oldest jobs in the book. Then a rehearsal of around 85 jobs from a fresh export. Each time we checked counts three ways (export, our ledger, the account) and the stage distribution, then ran the loader again and expected it to create nothing.
Three tiers. The whole book was too big to finish before go-live, so we loaded what the team needed on day one first.
Every run was reversible. A ledger keyed on SolarNexus ids recorded what each run created. A re-run skipped anything already there, and a rollback removed only that run's records. Each load had a deadline: if it wasn't confirmed by the time the team started work, it rolled back and they stayed on SolarNexus that day.
From the first export to go-live took about three months, most of it spent designing and testing the new workflow with the customer. The live loads themselves fitted into a single week.
A US solar and heat pump business with around 4,700 jobs, about 1,000 of them live, and more than 150,000 documents moved over this way. Crews worked on real jobs in Payaca during training week, and the migration didn't send a single message to a homeowner.
Automations are the real risk. Creating a project and placing it in a stage looks to Payaca like a new job arriving. Every migrated project carried a Nexus tag, customer-facing automations got a "does not have tag Nexus" condition, and the ones that couldn't be scoped that way stayed off for the load. The customer's own outside automations were paused too. Plan the tag's removal as its own step after go-live, because "days in stage" automations can wake up on it.
Stage guards still apply. A project created into a later stage effectively passes through the earlier ones, so guards are checked. We created each project in the first stage, moved it explicitly and read the stage back.
Don't merge customers on email. Hundreds of SolarNexus records shared an email address, often an office inbox used by several businesses, and around 150 jobs had none. We keyed identity on SolarNexus participant ids, agreed a survivor rule with the customer for shared emails, and kept names and phone numbers when an email was already taken.
Watch for duplicate exports. About 50 jobs came out in two folders each. We kept the folder with the larger document list and logged every decision for the customer to review.
Check the export is complete. One export listed far more documents than it actually contained. Compare what's indexed with what's there before you trust it.
One open-milestone rule. Many active jobs had no open milestone, and some had several. We placed jobs by their furthest open milestone, and never put a running job into a finished stage.
If you're on SolarNexus and weighing the move, book a walkthrough. We'll look at your processes, milestones and attributes, and show you where each one would land in Payaca. Guided onboarding on Growth and above includes the migration. The pricing page has the details.
SolarNexus is a trademark of its owner. Payaca isn't affiliated with or endorsed by SolarNexus.
See how Payaca helps clean tech installers save time and grow their business.
Request a demoWant more from Payaca in your Google results?
What came across, and what we rebuilt, when a US solar and electrical contractor moved its solar business off Scoop, with Zoho on the sales side, and onto Payaca. Written from the migration we ran.
US solar installers don't have one national permitting clock - they have as many as they have AHJs. Here's what that variance actually costs a growing install business, backed by NREL data.
Mid-sized US solar and clean-energy installers spend two engineers a year keeping a bespoke CRM alive that handles maybe 60% of the workflow. Permits, AHJ inspections, NEM interconnection and incentives end up on spreadsheets. The real cost of the build, and what the off-ramp usually looks like.