CASE STUDY · LEGACY SYSTEM MODERNIZATION
Modernising a client's legacy ERP without losing a single record.
- 48,000All 48,000 records accounted for
- 99.98%99.98% of fields matched automatically and the remaining exceptions were reviewed and corrected by hand
- 10Delivered within the 10-week window
01 · PROJECT OVERVIEW
The client and the brief.
An anonymised mid-market B2B services company. Name withheld under confidentiality.
Row-count and key-field checksums with financial-total reconciliation after each step, in a 3-week migration inside a 10-week programme.
- 1The company's ERP was out of vendor support.
- 2It held 48,000 records across 3 modules, and finance, operations and procurement all depended on it every day.
- 3Without vendor patches, the risk grew each quarter.
- 4The company also needed to move to a supported platform within a fixed window.
- 5The leadership had one firm condition: no record could be lost, and every number had to tie back to the old system.
02 · WHAT WENT WRONG
What went wrong, and how we fixed it.
Every engagement hits problems. These were the ones that mattered here, and what we changed so they did not come back.
- PROBLEM 01Our first full trial run left a group of exceptions in one module
Many records held free-text values in fields the new platform expected to be coded. Years of manual entry had produced several spellings of the same thing, plus a few blank values.
- PROBLEM 02We did not push the data through with defaults
We grouped the variants, agreed a mapping table with the business owners, and applied it in the migration script. The records that could not be mapped safely went to the manual review list. That added work, but it kept the final numbers honest and the reconciliation clean.
- PROBLEM 03That added work, but it kept the final numbers honest and the reconciliation clean
- PROBLEM 04Two weeks before cutover, a finance user found that an end-of-month report on the new platform used a different date cut-off
The old report included transactions posted on the last day after a certain hour. We traced it to a setting in the old system that nobody remembered. We aligned the new report, reran reconciliation on that period and added the rule to the documentation.
03 · THE PROCESS
How we ran it.
The 10-week programme had three stages.
- 01Analysis (early weeks)
we mapped the data model, the three modules and the rules between them. We agreed with the business which fields mattered most and what "match" meant for each.
- 02Migration (3 weeks)
data moved module by module in repeatable steps. After each step, reconciliation ran and results were reviewed.
- 03Validation and switch (remaining weeks)
users tested real scenarios on the new platform, exceptions were corrected, and the final cutover was rehearsed before it happened.
We ran a short weekly review with finance and operations leads. Open exceptions were tracked in a shared list with an owner for each.
04 · RESULTS
What changed.
Measured against the way the work ran before the engagement began.
- NOW 01
Data quality rules exist, and the new platform enforces coded values at entry.
- NOW 02
The business owns a documented mapping and exception process.
- NOW 03
Reconciliation reports are kept as audit evidence.
- NOW 04
The team treats migrations as repeatable scripts, not as one-off events.
- 48,000
All 48,000 records accounted for
- 99.98%
99.98% of fields matched automatically and the remaining exceptions were reviewed and corrected by hand
- 10
Delivered within the 10-week window
05 · WHAT WE BUILT
How it works.
- Row counts for every table moved.
- Key-field checksums, so identifiers and links between records stayed intact.
- Financial totals, compared to the old system at the account and period level.
- What went wrong, part two
- Two weeks before cutover, a finance user found that an end-of-month report on the new platform used a different date cut-off. The old report included transactions posted on the last day after a certain hour. We traced it to a setting in the old system that nobody remembered. We aligned the new report, reran reconciliation on that period and added the rule to the documentation.
- Controls
- The old system stayed read-only throughout, and a signed-off reconciliation report was required before each module was marked complete. Nothing moved forward on a verbal "looks fine".
- Handover
- We left the migration scripts, the mapping table and the exception log with the client, so any later audit question can be answered from records.
06 · QUICK ANSWERS
The short version.
- What problem did the client have?
- The company's ERP was out of vendor support. It held 48,000 records across 3 modules, and finance, operations and procurement all depended on it every day. Without vendor patches, the risk grew each quarter. The company also needed to move to a supported platform within a fixed window. The leadership had one firm condition: no record could be lost, and every number had to tie back to the old system.
- What did Brandsmashers build?
- Row-count and key-field checksums with financial-total reconciliation after each step, in a 3-week migration inside a 10-week programme.
- How was the work run?
- The 10-week programme had three stages.
- What were the results?
- All 48,000 records accounted for; 99.98% of fields matched automatically and the remaining exceptions were reviewed and corrected by hand; delivered within the 10-week window.
YOUR TURN
Have a similar requirement?
Tell us what is stuck. We will come back with a plan and matched, pre-vetted engineers.
