Business application rollout and data migration: planning the launch

Separate finished software from a working business change

Feature acceptance establishes whether an application performs the agreed tasks. Rollout establishes whether the business can use it with its actual records, people and working rules. The project schedule needs room for both.

Nominate someone in the business to decide questions about records and working practices. A developer can prepare an import and explain discrepancies, but should not guess which of two customer records is current or whether an old job was actually completed.

Also identify who will test the application as a user. If office staff and the people delivering work will both use it, someone from each group should try their own tasks before launch.

Decide which records need to move

Avoid beginning with “move everything”. Separate information needed for ongoing work from history that people only need to consult occasionally. Open jobs, active contacts and current products may need a different migration approach from old attachments and completed cases.

For each collection, identify its source, owner and purpose. If history stays in the old software or a separate archive, agree how it will be searched and accessed and how long the relevant records need to be kept. Do not assume that cancelling the old licence leaves continued access to everything the business requires.

The fictional example below describes a migration plan for a job management application. It illustrates decisions to make, rather than a standard import scope for every company.

Scroll the table sideways to read how each group of records will be moved and checked.

This separation also makes the work easier to estimate. Importing one organised spreadsheet is different from reconciling several systems and attaching thousands of files to the right records.

Agree what each field means

A column called “date” might refer to promised dispatch, the start of work or its completion. A status of “ready” might mean manufactured or already handed to the customer. Copying values without checking their meaning moves the same ambiguity into a new application.

Prepare a field map: where information comes from, where it will go and whether conversion or a decision is needed. Check units, date formats, identifiers, empty values and links to files. Do not invent missing information merely to make an import complete without errors.

Treat duplicate resolution as a separate task. Similar names are insufficient evidence for merging people or companies. Keep a review list for someone who understands the records to resolve uncertain matches.

Run a trial import and reconcile the result

Carry out the initial migration in a test environment. The information made available should be sufficient for the test and consistent with the agreed access arrangements. Record the source state before importing so that differences can be investigated.

Comparing row counts alone is a weak check. Also check customer-to-job relationships, quantity totals, dates, attachments and rejected records. Include ordinary records as well as incomplete data and unusual cases.

Ask users to complete a whole task with the imported information: find a job, open its document, update its stage and have the next person check the result. This tests whether the records are usable, rather than simply present in a database.

Keep a list of unresolved differences with a named decision-maker. A discrepancy should be corrected, accepted with an explanation or excluded from launch under an agreed rule. Quietly ignoring failed rows makes it harder to determine what the new application actually contains.

Define the cutover and the route back

Confusion is likely if employees do not know whether to record an update in the old system or the new one. Agree a clear cutover point: which records stop being editable, when the final import runs and who confirms readiness.

If some work temporarily remains in the old software, define the boundary. One possibility is completing existing jobs there while opening new jobs in the new application. Check whether that division works with reporting and relationships between jobs before adopting it.

The fallback plan should specify:

• who can pause the launch;
• which problems require a return to the old method;
• where employees record new activity during an interruption;
• how changes made in the new application will be reconciled after a return;
• how users are told which system to use.

A backup from before launch does not, by itself, account for jobs entered afterwards. The intervening activity needs an explicit plan so that reversing the launch does not discard completed work.

Train people on their own tasks

Training should cover the actions a person actually performs: receiving a job, finding a document, recording a blocker or checking a date. Working through a few typical tasks is more useful than touring every button.

Provide a short reference and one place for reporting problems. Distinguish a software defect, a question about use and a request for another feature. During the first days, someone also needs authority to resolve questions about working rules, not just technical issues.

Agree when the rollout is complete

Write completion conditions before launch: the agreed records have been checked, users can perform key tasks, the reporting route is known and ongoing responsibilities have owners. Separate problems that prevent work from improvements to consider later.

Check whether the supplier’s price includes migration, training and support after launch or lists them as separate work. For a discussion with brigdev, describe the task and current software, including the records that need to move. Add ongoing maintenance arrangements to the launch plan so backups, updates and support requests have clear ownership after acceptance.