Inventory the legacy application
Record the database or storage format, application version, data volume, and owners. Identify which processes still use the application and who can demonstrate each one.
- List the record types, relationships, attachments, reports, and history that need to be available after the move.
- Document forms, scheduled jobs, approvals, integrations, and service accounts. Include the downstream systems that rely on their outputs.
- Record what must remain searchable and what can move to an archive under your retention rules.
Test the extraction path
Use a documented API, a read-only database extract, a backup, or a supported export. Confirm that the extract includes stable IDs and references to related records and files.
- Pull sample records with missing values, special characters, long text, and large attachments.
- Check whether the export includes timestamps, owners, history, and a way to identify records added or changed after the initial extract.
- Estimate how long a full export takes and whether it can run within the agreed migration window.
Map the data and business rules to the new system
For each field, document the destination field, data type, allowed values, default, and conversion rule. Decide how the new application will represent records that do not fit its standard schema.
- Keep a source-to-target ID mapping so child records, files, and references can be reconciled.
- Map users, groups, and roles. Have application owners approve changes to access and ownership.
- Walk through approvals, notifications, and calculations with process owners. Record which steps need to be recreated and how they will be tested.
Pilot the migration with representative records
Run a small migration against a test destination. Include at least one complete business process, such as a request with an approval, multiple linked records, and attachments.
- Compare record counts, required fields, linked records, and a sample of files in both systems.
- Re-run the same batch to confirm it can resume or retry without duplicating records.
- Have business users verify that they can find the records, complete the process, and see only the data their roles allow.
Plan cutover and retire the source
Agree when changes stop in the old system, how you will capture the final changes, and who can delay or reverse cutover if the agreed checks fail.
- Assign owners to run the final migration, reconcile results, and resolve or sign off on exceptions.
- Keep the old system or an approved archive available until the business verifies access and records retention is confirmed.
- After sign-off, update integrations and support documentation, then disable obsolete accounts, jobs, and connections.