Legacy System Migration Checklist

1. Inventory the old system

• List every screen, report, export, email and scheduled job the old system runs.
• Interview the people who use it daily. Ask what they do around it: the workarounds are requirements too.
• Find every integration: file drops, ODBC connections, CSV exports someone emails each Friday.
• Note the technology and versions (for example Access 2010, PHP 5.6, Classic ASP, an old MySQL), the hosting and who has the passwords.
• Decide what will not move. Retiring unused features is one of the cheapest wins of a migration.

2. Map and clean the data

• Export the full schema and sample data.
• Map each table and field to the new model, including code lists and statuses ("S" might mean shipped in one table and suspended in another).
• Decide how much history to migrate. Sometimes recent years go into the new system and older data into a searchable archive.
• Fix character encoding issues (old Latin-1 databases often break pound signs and accents when moved to UTF-8).
• Write repeatable migration scripts, never one-off manual copies.
• Check personal data against your retention policy. A migration is a good moment to delete what you should not keep, as our UK GDPR guide explains.

3. Rebuild integrations and outputs

• Recreate links to accounting (Xero, Sage, QuickBooks), payments, couriers and ecommerce, using modern APIs where the old system used files.
• Rebuild document templates: invoices, delivery notes, statements.
• Recreate scheduled jobs with logging and alerts.
• For websites and shops, keep URL structures or set up 301 redirects so search rankings survive. dijitul has run shop migrations (CubeCart to OpenCart, osCommerce to CubeCart) that kept URL structures intact.

4. Test, rehearse and cut over

1. Run trial migrations into a staging copy and reconcile record counts, balances and stock totals.
2. Have real users run their daily tasks on staging with migrated data.
3. Write a cut-over runbook: freeze time, final export, import, checks, DNS or integration switch, sign-off.
4. Rehearse it at least once, timing each step.
5. Choose a quiet window and tell customers and staff.
6. Define the rollback trigger and how you would revert.
7. Keep the old system read-only for an agreed period.

For larger systems, consider a phased cut-over instead of one big switch: move one department, branch or module at a time, with the two systems synchronised during the transition. It takes more planning and some temporary integration work, but it limits the damage if something goes wrong and lets people learn the new system gradually.

Common legacy platforms and their pitfalls

• Microsoft Access databases. Often shared over a network drive, with business logic hidden in forms, queries and VBA macros. Export the queries and code as well as the tables, because the rules live there.
• Old PHP applications. Code written for PHP 5 or early PHP 7 may use removed functions (such as the original mysql_ extension) and insecure patterns. A PHP upgrade can sometimes save the application instead of replacing it.
• Classic ASP or old .NET Web Forms. Usually tied to old Windows servers. Migration often means a rebuild on a modern stack, with the database moved first.
• Desktop applications. Older desktop apps (Visual Basic, Delphi or Adobe AIR) may store data locally on each PC. Gather every copy before you migrate.
• Old ecommerce platforms. Shops on unsupported versions of osCommerce, CubeCart, OpenCart or Magento 1 carry security and payment compliance risks. Customer passwords usually cannot be migrated in a readable form, so plan a password reset journey.
• Bespoke systems with no documentation. Start with a code audit to map what the system really does before planning anything.

Whatever the platform, the database is usually the most valuable part. Even when the application is replaced entirely, a careful schema analysis gives the new system a head start.

5. After go-live, and when to talk to dijitul

Expect a settling-in period with small fixes. Monitor integrations closely, compare key reports between old and new, then archive and decommission the old system properly, including its backups. dijitul handles legacy software modernisation, data migration and ecommerce re-platforming. We begin with a free chat, assess the old system, then give a fixed-price quote or a phased plan.

Related