Migration is easier to discuss when it is tied to a recognisable business task. Choose one workflow that matters: preparing a customer order, renewing a membership, responding to a service request, scheduling a job or producing a management report. Trace what happens from the first trigger to a useful outcome.

Ask the people involved what they need to know at each point. Note where the information comes from, who can change it, what another colleague needs next and what happens when the usual route does not apply. This reveals the working context that may be missing from a field list.

A screen can then be assessed against real questions. Can a user find the current position? Can they see what needs attention? Can the next authorised colleague continue the task? A polished layout that cannot support those decisions is not yet a suitable design.

Axisware’s approach to workflow automation begins with the work and hand-offs, rather than assuming that the current forms or reports define the future system.

Most migrations involve more than one official database. Useful information may also sit in spreadsheets, document folders, email templates, shared calendars, exports from older applications and personal tracking lists. Some of these are temporary workarounds; others have quietly become essential.

Create a source map for the chosen workflow. For each source, record:

• what business information it contains;
• who owns and understands it;
• how frequently it changes;
• which task or decision depends on it;
• whether another source holds the same idea;
• any known gaps, duplicates or unusual conventions; and
• when a reliable extract can be produced for testing.

This map is not a promise that every source will be imported. It is a way to expose dependencies before a supplier or internal team estimates the work. A small spreadsheet used by one experienced colleague may deserve careful attention if it supplies the only dependable view of an important exception.

“Move everything” sounds safe, but it can carry old confusion into a new application. The opposite instruction — “only move active records” — may also be too simple when recent history helps staff understand the current position.

Group information into practical routes. Some records will move into the live system. Some may need correction or a clear transformation before they move. Some can remain available as reference through an agreed archive. Others may be duplicates, obsolete categories or material that the organisation decides not to carry forward.

The organisation must make its own decisions about retention, access and disposal in line with its policies and responsibilities. The migration project should make those decisions visible rather than quietly treating technical convenience as business approval.

Give each group a named owner and a reason. If nobody can explain why a data set is needed, that is a question to resolve, not an instruction to discard it. If several teams depend on the same information, agree which meaning and source will be authoritative in the new process.

Two columns can share a label without sharing a meaning. “Status” might describe progress, approval, payment or whether a record is still in use. A blank date might mean “not known”, “not required”, “not yet completed” or simply that an older system did not collect it.

Create a plain-language data dictionary for the important information in the chosen workflow. Define what each item means, who supplies it, when it can change and which values are valid. Include examples of awkward cases. This gives staff a chance to correct assumptions before those assumptions become import rules.

Only then map each retained source item to its destination. A mapping should say whether the value is copied, combined, split, standardised, calculated, reviewed or left out. It should also state what happens when the source is blank or invalid.

This is where business knowledge and software knowledge need to meet. The person who understands a legacy field may not know how the new application stores it. The developer may understand the new structure without knowing why a particular old code matters. Review the mapping together.

A tidy demonstration file can make a migration look simpler than it is. Test samples should include the records that staff find awkward: duplicates, missing values, old categories, long notes, inconsistent dates, linked people or organisations, unusual reference numbers and work that changed owner halfway through.

Use safe, authorised test material and remove identifying details where appropriate. The goal is to preserve the shape of the problem without sharing information unnecessarily.

Ask what the new process should do with each case. Some records may be corrected before import. Some may be flagged for a user to review afterwards. Some may need a specific exception rule. Record that decision beside the mapping so it can be tested again.

Sampling also helps with estimates. A simple record count does not reveal how many values need cleaning, how many attachments must remain connected or how many relationships are ambiguous. Early evidence makes the plan more honest.

The migration rules should be testable without relying on the final screen design. Produce a trial extract, apply the agreed transformations and load it into a safe test environment. Then compare the result with the source and the business expectations.

Check more than the total number of records. Reconcile categories, dates, totals and relationships that matter to the workflow. Trace a small number of examples from source to destination. Ask a knowledgeable user to find the information and explain whether it still means what it meant before.

Useful checks may include:

• every selected source record has a recorded outcome;
• required relationships still connect the correct records;
• agreed values have been translated consistently;
• notes and documents remain linked where they are needed;
• rejected or quarantined records are visible for review; and
• repeated trial runs produce an explainable result.

Keep a record of each issue, its owner and the decision taken. A failed trial is useful when it reveals a rule that can be corrected before live use.

The cutover is the period when work moves from the old route to the new one. It needs business decisions as well as technical steps. Agree when the old system stops accepting normal updates, when the final extract is taken and who confirms that the imported result is ready.

Decide how late changes will be handled. If somebody corrects a record after the extract, where should that correction be made? If an import must be repeated, which activities need to pause? If a critical check fails, what controlled fallback is available?

Write the sequence in ordinary language and assign each decision to a named role. Include communication for staff, support during the first working period and a route for recording issues. People should know which system holds the current position at every stage.

Avoid planning a long period in which both systems appear equally live. Parallel running can be appropriate in some circumstances, but unclear ownership creates new reconciliation work. If both routes are needed temporarily, define what each one is for and how differences will be resolved.

Once the team understands the sources, meanings, exceptions and checks, screen design becomes more useful. The interface can show the information people actually need, make uncertain or incomplete records visible and support the decisions identified during discovery.

Migration evidence may change the design. A user might need to see that an imported address has not been checked, that two records may be duplicates or that an old category was translated into a broader new one. Hiding those details for a cleaner layout can make the first weeks harder.

Conversely, not every migrated value needs to appear on the main screen. Some history can sit behind a clear summary. The interface should support the task, while preserving an appropriate route to the evidence users need.

Axisware creates bespoke software around the way an organisation works. That can include helping an organisation replace fragmented or overly manual processes with a system designed around its work. It does not mean bespoke software is always the answer; a sound migration plan also gives the organisation better evidence for judging whether an existing product can be configured or connected appropriately.

Define what “ready” means before the delivery date is under pressure. The measures should relate to the selected workflow and the risks found during testing. They might cover reconciled record groups, reviewed exceptions, successful user tasks, agreed ownership and the completion of support preparation.

Separate defects that block use from improvements that can wait. A missing relationship required to complete the workflow is different from a preference about the position of a button. Both can be recorded, but they should not compete as if they carry the same consequence.

After the move, review whether people can complete the chosen workflow without returning to private spreadsheets or the old system for essential context. Check the outstanding migration exceptions and confirm that each has an owner. The first live period is part of the migration, not proof that the work finished at the moment of import.

Before comparing new screens, gather the people who understand the work, the existing information and the intended change. Choose one important workflow. Map its sources, agree the meanings that matter, identify awkward records and define the checks that would make a trial trustworthy.

That short exercise will not answer every technical question. It will show whether the organisation is ready to estimate the migration, what evidence is still missing and which software choices deserve closer attention.

If you would like to prepare a practical data migration plan, contact the Axisware team. We can help you map one workflow, its information and a proportionate route to the next decision.