Most ERP migrations are a black box. A statement of work goes out, a go-live date gets set, and somewhere in between your data disappears into a process nobody explains until something goes wrong. For a contractor, that’s a lot to take on faith. Your job cost history, your payroll records, and your audit trail are the business, and “trust us” isn’t much of a plan.
So here is the ERP conversion process laid out stage by stage: what happens to your data, in what order, and why each stage exists. It’s the same sequence TransformerIQ runs on every engagement, whether a contractor runs it with their own team or works alongside a consultant.
Why we’re showing the work
Few providers in this space explain how a conversion actually works. Part of that is competitive instinct. Part of it is that the honest answer is often “it depends on who’s doing it.” Manual conversions get rebuilt from scratch every time, with different tools, different formats, and inconsistent results.
A standardized process is easier to explain precisely because it’s the same every time. TransformerIQ runs the construction data migration process as one sequential software pipeline with six stages, from Discovery through SQL Replicator. There is no mystery about what happens next, because the order doesn’t change from one engagement to the next.
Stage 1: Discovery
Every migration starts with Discovery. Its outputs, together with the analytics results from later in the pipeline, feed the automated configuration of the target environment. That’s a big part of how the pipeline replaces weeks of manual setup.
Stage 2: Source SQL Conversion
Sage 300 CRE keeps its data in a Pervasive database. The second stage moves that data automatically into Microsoft SQL. There are no manual exports, no custom scripts, and nobody asking your bookkeeper to produce a pile of spreadsheets and hope nothing was left out.
This stage matters more than it sounds. Every later stage works from a structured copy of your data rather than from whatever someone managed to export, which is why the rest of the process can be automated and repeated instead of rebuilt by hand.
Stage 3: PreFlight Analytics
Once your data is in SQL, analytics run before a single record is moved. This is the “know before you go” stage, and it’s where problems that have been sitting quietly in your system for years get found on your timeline instead of during cutover.
The checks are specific. Duplicate or incomplete vendor, customer, and company records are flagged, because they cause posting errors, duplicate payments, and AR reconciliation problems in a new system. Jobs where costs exceed estimates are surfaced for review so budget tracking doesn’t break after migration. The same goes for jobs where billings exceed contract amounts, which can point to overbilling or AR reconciliation issues, and for jobs with no customer assigned, since revenue and receivables can’t post properly without one.
Commitments get the same scrutiny: commitments with no vendor, commitments with no job, and commitments paid beyond their original amount. And your general ledger is checked against the AP, AR, and job cost subledgers, the alignment question behind most data integrity problems.
Every check comes with a plain explanation of why it matters, and the result is a quality score and a risk report. That report becomes your punch list. You see what needs attention before conversion, instead of discovering it afterward.
Stage 4: ERP Conversion
This is the stage most people picture when they think of a migration, and it’s where full transactional history either makes the trip or doesn’t.
Your GL, cost codes, phases, and prefixes get mapped to the target system. Configuration intelligence handles work that normally takes weeks of manual mapping. Then the data is loaded in automated, repeatable runs. Re-runnable matters here: if something needs to change, the load runs again with the correction instead of being redone by hand.
What moves is the part a balance-forward conversion leaves behind. Job cost detail by phase, cost type, and category. Committed costs, subcontracts, and change orders. AP and AR aging and payment history. GL balances and transactions. The audit trail. Source and target are reconciled at the transaction level, so the result is something your team can sign off on with evidence rather than hope.
Stage 5: Payroll Conversion
Payroll gets its own stage because it carries its own requirements. Payroll records and W-2 history move as part of this stage rather than being treated as an afterthought to the financial data.
If you’ve read our post on why payroll history is the migration landmine nobody talks about, you know why this matters: certified payroll reviews, union reporting, and prevailing wage audits can reach back years after a project closes, and they need records that exist at the detail level. Giving payroll a dedicated stage is how that history gets handled deliberately instead of by default.
Stage 6: SQL Replicator
SQL Replicator is the final stage of the pipeline. It covers replication after the conversion, so the process doesn’t simply stop at cutover.
A conversion that stops at go-live leaves you with a new system. One that carries history forward gives you a new system that already knows your business.
Two ways to run the same pipeline
The six stages are the same whether your own team runs them or a consultant does. TransformerIQ is built to work in both modes: self-service for a company’s own accounting team, or consultant-assisted, where a CPA firm or implementation partner runs the pipeline on your behalf. The same interface serves both, with the six stages as a navigation rail and the PreFlight analytics docked alongside.
That flexibility matters for contractors because it removes a false choice. You don’t have to pick between doing everything yourself and handing the whole thing to an open-ended consulting engagement. You can start with the assessment on your own, bring in help where you want it, and see the same stages and the same results either way.
Why carrying history forward is worth the effort
It’s fair to ask whether all of this is worth it. A balance-forward conversion is faster to set up, and for some companies it’s a legitimate choice. The tradeoff is that your history stays behind, and history isn’t just storage anymore.
Years of job cost data are what make estimating feedback possible, comparing estimated against actual by trade and phase across completed projects. They’re what makes it possible to flag a job whose burn rate deviates from comparable historical jobs before an overrun becomes a problem, to predict draw schedules and retainage release from real billing history, and to catch invoices that don’t fit historical norms for a phase or cost type. Every year of history you leave behind is a year those tools have to work without.
That’s the case for treating the migration process itself as something worth understanding. The stages exist to protect what your company has already built.
What this tells you about any migration provider
Whoever you work with, the same questions are worth asking:
- Is the process standardized and repeatable, or rebuilt from scratch on each engagement?
- Does extraction happen automatically from the source, or does it depend on exports your team has to produce?
- Will you get a data quality report before anything moves, and can you act on it?
- Is history migrated at the transaction level and reconciled source to target, or are only balances carried over?
- Is payroll history handled as its own stage?
- What happens after go-live?
A provider that can answer those clearly and show you the steps is giving you something a black box never will: the ability to check the work.
See where your data stands
Stage 3 is the one you can start with today. A free Pre-Flight assessment runs the same kinds of checks described above on your own data, so you know what’s in your system before anyone proposes a timeline or a price.
See where your data stands: start a free Pre-Flight at app.transformeriq.com