Published 24 October 2026 · dotNewLABS
When a vendor changes, the contract is the easy part. The hard part is the data: every file, feed, job and report that touched the old system has to keep working on the new one. This checklist is the order we would work in.
Start with an inventory, not a mapping. Include the obvious (databases, exports) and the easy to forget: scheduled jobs, nightly file drops, reports people open every Monday, spreadsheets that pull from the old system, and feeds sent to partners.
Most migration surprises are in the codes: status values, location codes, payer or product codes, date formats and blank fields that meant something. Build a field map in a spreadsheet your business people can read, and have the data owner approve it before anything moves.
Run the full move into a test copy several times. Each rehearsal should be scripted, so the final move is the same steps you have already run. Keep the scripts; you will want them again for the next vendor change.
Compare old and new with counts, totals and a sample of real records, and write the results down. See how to prove a data migration lost nothing.
Keep the field map, the scripts, the comparison results and who signed off. Examiners and auditors ask for evidence of how data was handled in a change, not just a statement that it went well.
Book a free 20-minute call about one app or data move: what it runs on, what's risky, and the shortest safe path forward. You keep a short written summary whether or not you hire us.
Book a free callOr email contact@dotnewlabs.ai