Data migration and legacy modernization
AS/400, Access, legacy ERP, and on-premise warehouse migrations, with reconciliation you can audit.
The system nobody wants to touch
Every mid-market company has at least one system like this: an AS/400 application from the 1990s, a Microsoft Access database that quietly became load-bearing, a legacy ERP module nobody fully understands anymore because the person who configured it retired years ago. It runs. Nobody wants to be the one who breaks it.
Migrating off a system like this is less about the destination platform and more about the migration itself: making sure every record, and every business rule buried in a stored procedure or a macro, survives the move.
We treat reconciliation as the deliverable, not an afterthought. A migration that moves the data but silently drops the edge cases is worse than not migrating at all, because now nobody knows what's missing.
What's included
- Legacy system assessmentWhat the system actually does, including the undocumented business rules living in macros, stored procedures, and tribal knowledge.
- Migration planningA sequenced plan that accounts for dependencies other systems have on the one being replaced.
- Data mapping and transformationField-by-field mapping from the old schema to the new one, with transformation logic documented, not buried in a script.
- Reconciliation and validationRecord counts, spot checks, and edge-case testing that prove the migration is complete, not just that it ran.
- Parallel run supportRunning old and new systems side by side where the risk justifies it, before the old system gets turned off.
- Cutover and decommissionA clean cutover with a documented rollback plan, and proper decommissioning once the new system is trusted.
How the engagement runs
- 01DiscoveryUnderstanding what the legacy system actually does, not just what the documentation claims.
- 02Migration designTarget platform, data mapping, and a reconciliation plan built before any data moves.
- 03Migration and validationData moved in stages, with reconciliation at each stage rather than one big-bang cutover.
- 04CutoverA go-live with a tested rollback plan, and decommissioning once the new system has proven itself.
Technologies and platforms
- AS/400
- Microsoft Access
- SQL Server
- PostgreSQL
- NetSuite
- Dynamics 365
Proof
This is a close cousin of the migration discipline behind our Cloud Migration and VMware Exit work: wave planning, validation at every step, and rollback points instead of one high-risk cutover weekend.
Common questions
What if nobody currently understands how the legacy system works?
That's the normal starting condition, not an obstacle. Discovery is built into the engagement specifically to surface the undocumented business rules before anything moves.
Do you migrate AS/400 systems specifically?
Yes, along with Access databases, legacy ERP modules, and on-premise warehouses more broadly.
How do you prove the migration didn't lose anything?
Reconciliation is the deliverable, not an afterthought: record counts, spot checks, and edge-case testing at every stage, not just a final row count.
Can the old and new systems run side by side during the transition?
Yes, where the risk justifies it. Parallel runs are a normal part of de-risking a migration before the old system is turned off.
Related services
Tell us about the system nobody wants to touch.
Every legacy migration feels uniquely difficult from the inside. Most have a workable path out.