Skip to content

Service 03

Retire the legacy system without losing a transaction.

A migration is judged on the records nobody notices. We count them, reconcile them, and itemise whatever will not key.

Shape
Build engagement
Systems retired
02
Failed records
0
One ERP and inventory system retired, counted per object
1,553Completed sales orders migratedPlus 8,478 order lines, across 16 archive objects, with zero failed records.
14,889Stock movements carried acrossAlongside 3,438 purchase orders, 2,862 invoices and 2,435 inventory items.
0Failed records across the loadEvery archive object fully populated. Failures were resolved before cutover, not counted after it.
97%Of cross-system value keyed on reconciliation97% matched. The residue was itemised rather than absorbed.

01What we migrate

Into Salesforce as the single record

Four system types, moved so that history stays queryable rather than stranded in an export.

  • 01

    ERP and inventory

    Orders, purchase orders, stock movements, assemblies and bills of material into archive objects that stay reportable. Inventory value becomes a number somebody can look up rather than a quarterly exercise.

  • 02

    Quoting

    Historical quotes carried across with their line detail, so close ratios can be computed rather than estimated.

  • 03

    Accounting

    Invoices and payments joined to the live ledger on a legacy key, with duplicates resolved by an explicit rule rather than by judgement.

  • 04

    Professional services systems

    Projects, time and the work-in-progress that sits between them, so finished work stops going unbilled.

02The reconciliation, drawn

A total nobody can defend is not a total.

A migration is a reconciliation, not a copy. Every dollar that lands carries the method that put it there, and the amounts the engine will not vouch for are published beside the number.

  • The old system, the new org and the accounting ledger, joined on the legacy order key.
  • 97% keyed across all three. What did not key was itemised order by order.
  • Duplicates resolved by a written rule rather than by judgement on the day.
  • Any single invoice above a stated ceiling is excluded as a data error, and listed as one.
141 of 141Order files that agree or carry a written explanationPer-order reconciliation across the transition window, 2010 to 2026. Every transaction in the window, not a sample.
Sales and Forecasting
How the projection is built
Backlog, remaining to bill on open ordersA
−Marked finished, nothing left to billB
=What the engine spreads across monthsC
+Eligible pipeline, not signedD
=ProjectedC + D
What this number does not vouch for
DatesReview missing or outdated scheduling information.
MappingReview records without a confirmed source-system match.
ValidationResolve flagged records before accepting the projection.
Depiction · A revenue forecast that prints its own arithmetic. Every row carries the method that placed its dollar, so a controller can defend the total line by line.The panel on the right is the part most forecasts omit: the amounts the engine will not vouch for, published beside the number rather than discovered in an audit.
Contact us to find out more

Tell us which system you are trying to switch off.

0Failed records across the loadAcross 16 archive objects, every one fully populated before cutover.

04The reconciliation

Three-way, and honest about the residue

The old system, the new one and the accounting ledger, joined on a legacy order key and reconciled line by line.

  1. 01

    Join on the legacy key

    Two retiring systems and one live system feed 16 archive objects plus live invoices. A recompute joins everything on the legacy order key and writes three financial fields.

    16 objects
  2. 02

    Resolve duplicates by rule

    An invoice is a duplicate if it falls in the transition window and matches another within one dollar and seven days. Any single invoice above a stated ceiling is excluded as a data error rather than argued about.

    Stated rule
  3. 03

    Reconcile against the ledger

    The live era plus the completed era, reconciled against the accounting system. Pre-2026 records agreed to the dollar on 54% of orders, with totals within 17%.

    97% keyed
  4. 04

    Itemise what did not key

    The the residue residue was listed order by order rather than absorbed into a rounding line. A reconciliation that hides its own residue is a reconciliation nobody can defend.

    the residue listed
  • The retired system. Read as it stood on its last day, including the data it had inherited from the system before it.

  • The new Salesforce org. Read after load, under the same permissions the finance team will use on the Monday.

  • The accounting ledger. The record of what was actually owed and paid. It arbitrates the other two.

Reconciliation file
Window
2010 → 2026Every transaction in the window, not a sample.
Transactions
4,506Joined on the legacy order key across all three systems.
Keyed
97%Keyed across all three systems by the reconciliation. What did not key is the row below.
Unkeyed
The residueItemised order by order for their controller. Not absorbed into a rounding line.
Per order
141 of 141Every order file either agrees or carries a written explanation.
97% keyed · 3% itemised
05 / The forensic catch

Validate historical records before they reach a live workflow.

Keep historical records separate from operational records. Reconcile against the source and route exceptions to authorised reviewers. Client financial findings remain private.

Source references preserved through migration.

We will tell you what will not key before you sign anything.

Next step

Tell us which system you are trying to switch off.

Tell us what you need to migrate and when. We will discuss the fit, then scope the mapping, validation and cutover work.

  • Free fit conversation
  • Scope and fees agreed before kickoff
  • Vancouver, British Columbia