Start here.
Choose which records the new app needs, agree what each piece of information means, and name someone to resolve unclear cases. Try a sample transfer before the full move. Check that staff can finish real tasks from those records, then agree when updates stop in the old system and start in the new one.
- Moving every old record is a choice to discuss, not an automatic requirement for launch.
- The people who understand the records need a part in checking them; the developer cannot settle every business ambiguity.
- Plan where staff will record work during the switch, including anything that changes after the final copy is taken.
What needs to come across for the first day?
Imagine a business moving a customer list and open jobs from two spreadsheets into a new app. The examples in this guide are invented planning situations, not a project we have delivered.
Start with the work staff must finish after the switch. If someone needs to find an open job, contact the right customer and check the latest agreed details, those records belong in the launch conversation. Older completed jobs may serve a different purpose.
Ask whether older information needs to be available inside the app or whether an agreed way to look it up elsewhere would be enough. Consider who needs it, how often, and whether leaving it outside would interrupt ordinary work.
Write down what will move, what will remain elsewhere, and what is still undecided. Include attachments and notes in that discussion rather than treating the spreadsheet rows as the whole job.
Who decides what an unclear record means?
Ask someone who works with the information to review a sample with the supplier. A column headed “done” might mean that work is finished, an invoice was sent, or a customer has approved the result. Agree the meaning before choosing where it belongs in the app.
Do the same for customer names, dates, job references and notes. If two files disagree, decide which source should be trusted or who will investigate. Do not ask the supplier to guess which version reflects your business.
Possible duplicates need a decision too. Two similar names may describe one customer entered twice, or two different people. Ask how uncertain matches will be held for review and how the original references will remain traceable.
The table below shows decisions to discuss for our hypothetical business. It is a planning aid, not a claim about what any import tool can do.
| Existing information | Decision before the move | Check in the new app |
|---|---|---|
| Two customer entries with similar names | Who confirms whether they represent the same customer? | Each open job belongs to the intended customer |
| A job marked “done” | What exactly does that label mean? | The status matches the agreed business meaning |
| A note referring to a separate file | Which attachment belongs with it, and who should see it? | The right person can open the right document |
| A changed date in a second spreadsheet | Which date is current, and who can confirm it? | The current date is visible where staff need it |
What should a trial transfer prove?
Ask for a trial using representative records before agreeing to the full move. Include an ordinary job, a job with several documents, and examples with missing or disputed details. A sample made only of tidy records leaves the difficult questions unanswered.
Check the resulting work, not just whether a file was accepted. Can a member of staff find the customer, open their job, read the relevant note and continue from the correct next step? Check which people can see information that should be restricted.
Compare the trial with the source. Ask which records were included, which were left out, which changed, and which need attention. Counts can help you find differences, but a matching total does not tell you that each job is attached to the right customer.
Keep a short list of corrections and repeat the affected checks after they are resolved. Agree what would make the full move unacceptable and who has authority to approve it.
Where will staff enter work during the switch?
Choose when the final source copy will be taken and tell staff where to record changes after that point. A customer may call while the transfer is running. Someone needs to know where the new details belong.
If work must continue in an old tool temporarily, agree how later changes will reach the new app and who will check them. Avoid leaving staff to decide between two competing versions of the same job.
Write down the order of the switch: the last updates in the old place, the transfer, the checks, approval, and the start of work in the app. Include the people who need to be available for those steps.
Ask what happens if the checks fail or the move takes longer than expected. Your team needs an agreed way to keep working while the supplier investigates, including how any work recorded during that period will be accounted for.
What should happen to the old files?
Agree how the original records will be preserved for checking and how access will be managed after the switch. Do not treat a successful sample as a decision to remove the old system.
Decide whether staff will still need to look up older material and how they will know it is a reference copy. If people keep changing the old files, the business needs to understand which place now holds the current answer.
Keep a record of what moved and any exceptions still awaiting a decision. If someone reports a missing attachment later, that record gives your team and supplier a starting point for investigating.
Make any later decision about closing an account or removing files separately, with the people responsible for the business records. The transfer plan should explain the next decision, not assume it has already been made.
What should the project agreement include?
Ask the supplier to describe the records, files and checks included in the proposed work. Name the preparation your team will do, the unresolved questions, and who decides what happens to exceptions.
Discuss what happens if the sample reveals more cleanup than expected. You may choose to resolve records internally, narrow what moves at launch, or agree additional work. Ask for the effect on cost and timing before choosing.
Keep an ongoing connection separate from the one-time move. Bringing old jobs across does not by itself establish that future changes in another tool will appear automatically. If you need both, ask for both to be explained.
You should finish the conversation able to describe what staff will find on the first day, who checks it, and where the next new job will be recorded. That is a more useful agreement than “import our spreadsheets”.
Bring a sample and a list of decisions.
For an initial discussion, use made-up or appropriately anonymised examples that preserve the structure of your records. Arrange any later access to real information for an agreed purpose.
- What you use today
- List the files, tools, notes and attachments staff consult to finish one current job.
- What must be available at launch
- Separate active work from older information people only look up occasionally.
- What needs a decision
- Identify conflicting details, possible duplicates and shorthand only your team understands.
- How you will accept the move
- Name the staff checks, the person who approves the result and the plan if the move needs to pause.
A couple of common questions.
Do we need to clean up everything before talking to a developer?
Bring a representative sample and show the problems you already know about. Agree which decisions need someone in your business and which preparation the supplier can help with. Sorting every historical record may be unnecessary if it is outside the agreed first move.
Can we keep our old software while we try the new app?
Discuss a limited trial and decide where the current record will live. If staff can change information in both places, agree how differences will be found and resolved. Ask what your existing supplier allows and what access you would retain during the trial.