When a construction client asks their CPA or VAR whether it’s time to move off Sage 300 CRE, the conversation almost always centers on the new system. Which platform. Which modules. How long it takes. What it costs.
The question that gets skipped is quieter, and it matters more: what actually comes along for the ride when the data moves.
It’s an easy question to skip, because it doesn’t show up on any implementation checklist and nobody asks it out loud during vendor selection. The new platform gets evaluated on modules, pricing, and go-live timeline. What rarely gets evaluated with the same rigor is whether the migration itself will carry forward the transaction-level detail underneath the client’s job cost, payroll, and change order history, or just the ending numbers.
Most ERP migrations, by default, are balance-forward conversions. They carry over ending balances so the new system opens with the right numbers on the books. On paper, that looks like a clean cutover. In practice, it means everything underneath those balances, the transaction-level detail that explains how the company got there, gets left behind in the old system or archived somewhere nobody will open again.
For a lot of businesses, that tradeoff is fine. For a construction company, it usually isn’t. Job cost detail, payroll history, and change order records aren’t just backup documentation. They’re the evidence base auditors, sureties, and litigation teams reach for when something needs to be explained.
What “balance-forward” actually discards
A balance-forward migration moves the ending numbers. It doesn’t move the path that got there.
That means the new system knows what a job’s WIP balance is on day one, but not the sequence of change orders, cost code adjustments, and billing events that built up to it. It knows current payroll setup, but not the certified payroll history tied to specific jobs and unions. It knows today’s AP/AR balances, but not the invoice-level detail and supporting documentation behind them.
None of this shows up as a problem at go-live. The new system works. The dashboards look fine. The gap only becomes visible later, when someone needs to answer a specific question about a specific job, and the answer used to live in a system that’s since been decommissioned or is quietly rotting in a read-only archive nobody remembers the login for.
Why balance-forward is the default, not a deliberate choice
It’s worth being fair to how this happens. Nobody sits down and decides to throw away job cost history on purpose. Balance-forward becomes the default because it’s faster and cheaper to execute, and because most implementation partners are scoped and staffed to stand up a new platform, not to reconcile years of legacy transactional detail against it.
From an implementation timeline, moving balances is a matter of weeks. Moving full transactional history, in a way that keeps AP/AR, Job Cost, WIP, and the General Ledger reconciled against each other, is a fundamentally different scope of work. Left unstated, that difference in scope quietly becomes a difference in what the client actually receives, and most clients never find out which version they got until they need the history that isn’t there.
Where the gap actually costs money
Audits Auditors testing job cost or WIP schedules routinely need transaction-level support, not just period-end balances. If that support only exists in a legacy system that’s hard to access, or worse, was never carried forward at all, audit fieldwork slows down and the firm’s exposure to findings goes up.
Bonding Sureties evaluate a contractor’s job cost history and change order discipline as part of underwriting and renewal. A contractor that can’t produce clean historical detail on completed projects, because the detail didn’t survive the migration, is telling its surety a story it didn’t mean to tell.
Litigation support Construction disputes, delay claims, and change order fights routinely get resolved by pulling the exact sequence of cost entries and approvals tied to a job. If that sequence lives only in a decommissioned system, or was flattened into a single balance during migration, the client’s legal team is working with a fraction of the record they actually had.
In every one of these situations, the missing history isn’t a hypothetical risk. It’s a real gap that shows up exactly when the client can least afford it, in front of an auditor, an underwriter, or opposing counsel.
Why this is an advisory conversation, not just an IT one
This is exactly why the migration conversation shouldn’t start and end with the CPA or VAR recommending a platform. The platform decision (Sage Intacct, Acumatica, or otherwise) is usually the easy part. The harder, higher-stakes decision is what happens to the data underneath it, and that’s a decision advisors are well positioned to influence before a client ever signs a statement of work with an implementation partner.
Advisors who raise the balance-forward question early are doing their clients a real service. It’s a natural extension of the same due diligence CPAs already apply to financial statements and VARs already apply to system design. The clients who get burned by this gap are rarely the ones who were told about the risk in advance and chose to accept it. They’re the ones who never had the conversation at all.
Raising it doesn’t require becoming a migration expert overnight. A short list of questions does most of the work: How far back does the client need job cost and change order detail to survive, given their audit cycle and any active litigation or claims? Are there jobs still in WIP that carry certified payroll or union reporting history the new system will need? Has anyone actually confirmed whether the implementation partner’s default scope includes full transactional history, or only balances? Asked early, in a planning conversation, none of those questions are confrontational. Asked two years later by an auditor, they’re a very different kind of conversation.
What a full-history migration actually preserves
TransformerIQ’s approach to construction ERP migration is built around preserving full transactional history, not just point-in-time balances. That means Accounts Receivable moves with complete invoice-level detail and supporting documentation, Accounts Payable moves the same way, Job Cost carries over existing work-in-progress along with the transactions that built it, and the General Ledger moves with full account balances and transaction history intact. AP/AR, Job Cost, WIP, and the General Ledger all move forward together, fully reconciled against each other, instead of arriving as four disconnected sets of numbers that happen to tie out on day one.
Before any of that data moves, TransformerIQ’s ERP Data Integrity Assessment looks at the current state of the system: whether subledgers are actually aligned with the general ledger, and where risks, inconsistencies, or structural issues exist that could compromise the migration or cause problems downstream. That assessment is the diagnostic step that turns “we think our data is fine” into an actual answer, before a client commits to a platform or a timeline.
Two other pieces of the approach matter specifically for the audit, bonding, and litigation-support concerns above. WIP Replication keeps ongoing project reconciliations current in real time, rather than treating WIP as a static balance that only gets revisited at period-end. And the Readiness & Analytics module provides pre-migration insights and system health checks up front, along with a post-migration analytics foundation, so the client isn’t just hoping the historical detail made it across cleanly. There’s a way to verify it did.
Taken together, this is the difference between a migration that gives a client a new system with a clean opening balance, and one that gives them a new system that still knows everything the old one did.
The question worth asking before the platform decision
The right moment to raise the balance-forward question is before a client has picked a platform or signed with an implementation partner, not after they discover a gap during an audit two years later.
A useful starting point: has anyone actually looked at what this client’s data looks like today, and what a full-history migration versus a balance-forward one would mean for their job cost, payroll, and change order records specifically?
TransformerIQ’s Pre-Flight Analytics assessment answers that question directly, giving a clear picture of migration complexity, cost, and timeline before any commitment is made. For CPAs and VARs advising clients through a Sage 300 CRE transition, it’s a low-friction way to bring data integrity into the conversation early, while there’s still time to choose full history over a balance-forward shortcut.
The advisors who bring this up before a platform is chosen are the ones clients remember later, especially the first time an auditor, a surety, or opposing counsel asks a question that a balance-forward migration simply can’t answer.
Share a free Pre-Flight Analytics assessment with a client who’s evaluating a migration now, or schedule a partner briefing to walk through how this applies to a client you’re currently advising.