A new business app may have a clean interface and a better workflow, but it still has to deal with the records left behind by the old system. Customer details, job histories, notes, document links and account statuses rarely arrive in one tidy file.
Custom app data migration needs its own plan. Treating it as a last-minute export and import can leave the new app full of duplicate records, unexplained gaps and values that no longer mean what staff expect them to mean.
Decide what needs to move
Start with an inventory of the current sources. That may include the main database, spreadsheets used by individual teams, shared folders, email exports and data held by another software provider. Record who owns each source, what it contains and how recently it has been updated.
Do not assume every old record belongs in the new app. Some information must remain available for day-to-day work. Some may need to be retained outside the app. Other material may be duplicated, obsolete or impossible to interpret safely. Agree those decisions with the people responsible for the information rather than asking a developer to infer them from a spreadsheet.
- List each source and the person who can explain it.
- Mark which records are needed in the first release.
- Separate material that should be archived or reviewed.
- Record any retention or deletion decision that needs specialist advice.
Map the old fields to the new app
A field called “status” might mean enquiry stage in one system and payment state in another. A blank date might mean “not booked”, “unknown” or simply that an old form never collected it. Matching field names is not enough.
Create a mapping sheet that pairs each source field with its destination. Include the expected format, any conversion rule, the treatment of blanks and the person who approved the meaning. If several old values will become one new value, write that rule down. If a value cannot be converted reliably, send the record to a review list instead of quietly guessing.
Clean with agreed rules
Migration often exposes inconsistent phone numbers, duplicate customer entries and categories that have grown through years of ad hoc typing. Clean-up is useful, but only when the rule is understood. Two people with similar names may be different customers. An old account marked inactive may still have a service history that staff need.
Automate safe corrections such as a known date format. Put uncertain cases into a review queue. This takes longer than deleting every apparent duplicate, but it leaves a decision trail and reduces the chance of losing useful history.
Protect the source before changing anything
Keep an untouched copy of the source data before cleaning or importing it. Limit access to the people doing the work, store exports in an agreed location and remove temporary copies when they are no longer needed.
The National Cyber Security Centre advises organisations to back up the data they need to operate and to check that important data can be restored. For a migration, that means knowing how to recover the source and the new system if an import fails. A file labelled “backup” is not much comfort if nobody has tested whether it opens or restores correctly.
Test a sample, then rehearse the full move
Begin with a small sample that contains ordinary records and awkward ones. Include blanks, long notes, old dates, special characters and records linked to other records. Check the result in the new app with the staff who understand the work, not just the technical team.
Once the sample behaves properly, run a full rehearsal in a test environment. Compare record counts, totals where they are meaningful, key dates and a selection of individual histories. Keep a report of rejected or changed records. A successful import message only proves that the import process finished; it does not prove that the information is complete or useful.
Plan the cutover and rollback
The final move needs a short runbook. Set the point when people must stop changing the old system, who takes the final export, who runs the import and who checks the result. Tell staff what will be unavailable and where urgent work should be recorded during the gap.
Define the conditions for going back. If important linked records are missing, totals do not reconcile or the app cannot support a core task, the team should know who can stop the launch and restore the previous service. Keeping the old system available in read-only form for an agreed period can help with checks, provided access and retention have been considered properly.
Put migration into the project brief
Data migration affects the scope of a custom business app long before launch week. The brief should name the sources, likely volume, data owners, clean-up rules, test process, cutover responsibilities and acceptance checks. Unknowns should be visible so they can be investigated rather than hidden inside a fixed estimate.
If the process has already outgrown forms, inboxes and spreadsheets, the studio’s approach to SaaS tools and automation starts with the workflow and the job the software must do. Bringing the data discussion into that early planning makes the first useful version easier to define and safer to introduce.