Software Migration: How to Migrate in 7 Steps

Short answer: Migrate to new software as an ordered sequence, not a single import: audit and back up your data, clean it and map every field, run a test migration into a sandbox, load the real data, validate that it arrived correctly, train the team, then retire the old system deliberately. Preparation decides the outcome, cleaning and mapping takes longest, and a complete backup with the old tool left read-only keeps the whole move reversible.

Software migration is the planned move of your business records, files, and daily workflows out of one system and into another, run as an ordered sequence rather than a single import: export the data, clean and map it, load it, prove it arrived correctly, then train the team and retire the old tool. That is the whole definition, and it applies whether you are moving a CRM, a set of books, a help desk, a quality management system, or a practice management platform.

Migrating software is the moment the tool you carefully chose either proves itself or falls apart, because the new system is only as good as the data that arrives with it, and that is where most moves quietly go wrong. A team picks a better tool, signs the contract, clicks import, and then spends the next month discovering that half the customer records lost their phone numbers, that the historical invoices did not come across, and that nobody can find last year’s project notes. Knowing how to migrate software data cleanly is a separate skill from choosing the software, and it is the one that decides whether the switch feels like an upgrade or a disaster. The good news is that a safe migration is not about clever tooling. It is about doing a handful of unglamorous steps in the right order, so that nothing moves until you have proven it will move correctly.

This walkthrough runs that sequence end to end. Over seven steps you will audit the data and workflows you actually have, plan a realistic scope and timeline, clean and map the data before it moves, back up everything so the process is reversible, run a test migration to catch problems on a copy, execute and validate the real cutover, and then train your team and retire the old system deliberately. It builds on our software trial walkthrough for the evaluation that comes before this, our true-cost verdict for the money side of switching, and it sits alongside our walkthroughs for choosing a CRM, accounting software, and HR software, because a migration is what turns any of those choices into reality. Past the steps it goes deeper than a checklist: a full section on data migration and the four places records quietly break, a section on software migration by system type covering CRM, accounting and ERP, HR and payroll, and help desk, because each category strains at a different joint, and a separate section for anyone working out how to migrate to new QMS software, a practice management system, or anything else where the records are evidence rather than data. Keep the readiness helper on this page open as you read, and size your own move as you go.

Software migration defined: what migrating software involves

A migration of software is the planned move of your business records, files, and daily workflows from one system to another, and it helps to see the whole shape before diving into the steps. Every software migration, whatever the tools involved, is built from the same five parts. First comes data export and import: getting a complete copy out of the old system, usually as spreadsheet-style files or a structured export, and loading it into the new one through an import template or a built-in migration tool. Second is the mapping between the two structures, the field-by-field decisions that Step 3 covers in depth, because the old system’s shape never matches the new one exactly. Third is the running arrangement, whether you switch in a single hard cutover or keep both systems live for a short parallel period, a choice this walkthrough weighs after the steps. Fourth is the cutover itself, the defined moment the new system becomes the source of truth. Fifth is everything after: validation, training, and the deliberate retirement of the old tool, which ends with cancelling the old subscription cleanly, a task our cancellation walkthrough handles in its own right.

Seeing those five parts also explains why migration effort has almost nothing to do with the sticker price of the tools. A team moving to a modestly priced system, the kind our CRM cost verdict breaks down, can face a heavier move than a team buying something expensive, because the effort tracks the state of the data and the number of connected systems, not the invoice. It is also worth separating a migration from an upgrade: an upgrade keeps you on the same product and usually preserves your data structure automatically, while a migration changes the structure the data lives in, and that structural change is where records get lost, truncated, or silently reshaped. That distinction is why the rest of this walkthrough spends its effort on data quality and verification rather than on any particular tool.

Before you start

A software migration rewards preparation more than almost any technical project, and the preparation costs little beyond an afternoon of honest listing. Before you move a single record, gather three things about your situation, because they change every decision that follows.

First, an inventory of what you are moving: which systems hold your data today, roughly how many records live in each, and what kinds of data they are, structured records like customers and invoices, unstructured items like notes and files, and historical archives you may or may not need to carry forward. Second, a map of how your team actually uses that data day to day, because a migration that preserves the records but breaks a workflow your team depends on has not really succeeded. Third, the constraints around the move: any reporting periods, billing cycles, or busy seasons you must avoid, who needs to be involved, and how much downtime your operation can tolerate during the final cutover.

Time and difficulty: expect anywhere from a focused week for a small, clean, single-system move to several weeks for messy data spread across connected tools, with most of that time going to cleaning and mapping rather than the transfer. The work is not technically hard for a typical business dataset, but it is easy to underestimate, and underestimating it is how teams end up doing a rushed cutover with no backup. Write these three inputs down now, enter your record count, data cleanliness, scope, and whether the system is a standard or a regulated one into the helper on this page, and let the rest of this walkthrough turn them into a plan.

Step 1: Audit your current data and workflows

Before you plan anything, take a full inventory of the data you have and how your team uses it, because you cannot migrate what you have not accounted for. This is the step buyers most often skip in their eagerness to start the new system, and skipping it is exactly how historical records and one important custom field get left behind. Open the old system and list every kind of data it holds: the core records like customers, contacts, invoices, projects, or employees, the supporting items like notes, tags, attachments, and comments, and the historical data like closed deals or past reports that you may need for reference or compliance.

For each kind of data, note roughly how many records exist and how clean they are, because a table full of duplicates and half-empty fields is a very different migration from a tidy one. Then, and this is the part that separates a good migration from a lossy one, watch how your team actually works with the data. Which fields do they rely on that a generic export might not capture? Which reports would break if a field arrived empty? Which integrations feed data in or out of this system? A migration that moves the obvious records but drops the attachments your support team needs, or breaks the feed into your accounting software, has moved the data and broken the work.

Watch out for the hidden data that lives outside the main tables: file attachments, email threads, custom fields someone added years ago, and the archive nobody has opened in months but that an auditor might ask for. List all of it now, mark each item as must-migrate, archive-only, or leave-behind, and you turn a vague “move everything” into a concrete inventory. Enter your record count and how clean the data is into the helper so the later steps can size the effort honestly.

Step 2: Plan the scope and timeline

With your inventory in hand, decide exactly what is in scope and when the move will happen, because an unscoped migration expands until it collapses. Scope is the discipline that keeps a two-week move from becoming a two-month one. Go back to the inventory from Step 1 and make a firm call on each item: which data migrates into the new system, which gets archived to a separate export you keep but do not import, and which you deliberately leave behind because it is stale or duplicated. Not every record earns a place in the new system, and carrying dead data forward just clutters the tool you are paying to improve your work.

Then build a timeline that respects the reality of your calendar. Identify the busy seasons, reporting periods, and billing cycles you must avoid, and schedule the cutover for a genuinely quiet window, because a migration in the middle of month-end close or your busiest sales week multiplies every risk. Work backward from that cutover date through the cleaning, mapping, test, and validation steps so each has real time rather than being crushed into the final weekend. An illustrative small-business timeline might allow a few days to audit and plan, several days to clean and map the data, a couple of days to back up and run tests, a short window for the cutover itself, and a few days to validate and train, but your own shape will differ.

Watch out for the two classic scope errors. The first is scope creep, where “just move the customers” quietly grows into “and the projects, and the archives, and this other tool,” until the project loses its edges. The second is false economy, cutting the timeline so short that cleaning and testing get skipped, which is where the expensive failures live. Set a scope, defend it, and give the data-quality steps the time they actually need. Size an illustrative effort and cutover window for your own inputs in the helper on this page.

Step 3: Clean and map the data

This is the step that decides whether your migration is an upgrade or a mess relocated, and it is reliably the one that takes the longest. Migrating dirty data does not fix it; it moves it into a new system where it is harder to untangle. The migration is the one natural moment when every record passes through your hands, so it is the cheapest opportunity you will ever get to clean the data properly. Take it.

Cleaning comes first. Remove duplicate records, merge the ones that describe the same customer or project, fill or flag the important gaps, standardize formats so dates, phone numbers, and states all follow one convention, and drop the records you already decided to leave behind in Step 2. Then map the data, which means deciding, field by field, where each piece of information in the old system lands in the new one. Most fields map obviously, name to name, email to email, but the ones that matter are the awkward cases: a custom field with no equivalent, a single “address” field that must split into several, a status value the new system names differently, or attachments the importer handles separately.

Watch out for silent drops, where a field that has no mapping simply vanishes without warning. Go through the new system’s import template and confirm every must-migrate item from your inventory has a destination, and decide explicitly what happens to anything that does not. Keep a written mapping document, because you will refer to it during the test and the validation, and it is the record of what should have moved. On your inputs, most of the effort the helper shows lands here, in cleaning and mapping, not in the transfer, which is exactly where a careful migration spends its time. List-based tools add wrinkles of their own: the list-import gotchas covered in our email marketing pricing verdict are a good example of the traps a per-subscriber tool layers on top of a standard migration.

Step 4: Back up everything

Before any data moves, take a complete backup of the source system, because this is the single step that turns a migration from a one-way gamble into a reversible operation. Everything after this point is safer simply because you did it. A backup means a full export of your data in a format you can actually restore or read later, stored somewhere independent of both the old and the new system, so that if the migration corrupts or loses something, you have an untouched original to go back to.

Take the backup as close to the cutover as practical so it captures the latest data, and verify it is real and complete rather than assuming the export worked. Open the file, check that the record counts match what the system reports, and confirm the important fields and attachments are actually inside it, because a backup you have not checked is a hope, not a safeguard. Store at least one copy somewhere separate from the systems involved, so a problem with either one cannot take your backup with it. For most small businesses a full data export plus a copy of any attachments, saved to independent storage, is enough; the point is that a clean, verified copy exists outside the migration path.

Watch out for treating the vendor’s “we keep backups” as your backup. The old vendor’s internal backups protect their service, not your migration, and they may be hard or impossible to get in a usable form once you cancel. Your own independent export is the one you control and the one that makes a fast rollback possible if the cutover validation fails. A migration with a verified backup behind it is a managed risk you can undo; one without is a leap you cannot take back, which is why this step is never the one to skip when the timeline gets tight.

Step 5: Run a test migration

Now prove the whole thing works on a copy before you touch anything live. A test migration into a sandbox, a trial account, or a separate test environment is the most valuable safeguard in this entire process, because it shows you exactly how your real data behaves in the new system while there is still zero cost to getting it wrong. Do not test with fake sample data; use a real, representative slice of your actual records, including the awkward ones, the record with every custom field filled, the customer with attachments, the historical entry, so the test exercises the cases most likely to break.

Run the migration into the test environment using the mapping you built in Step 3, then check the results carefully against the source. Did the record counts match? Did the fields land where the map said they would? Did dates, currencies, and special characters survive intact, or did something get truncated or reformatted? Did the attachments and custom fields come across, or did the importer skip them silently? When you find problems, and a first test almost always finds some, fix the mapping or the source data and run the test again. Repeat until a test run comes through clean, because each clean test is evidence that the real cutover will behave.

Watch out for confusing a smooth import with correct data. An import that finishes without an error message can still have dropped a field or reformatted every phone number, so the check is not “did it run” but “is the data right.” Where a vendor offers a guided or assisted migration, run your own validation on their results anyway, because their tool is measuring its own success, not your data’s correctness. The test migration is also where you learn how long the real one takes, which sharpens the cutover window you planned in Step 2.

Step 6: Execute and validate the cutover

With a clean test behind you, a verified backup in hand, and a quiet window chosen, run the real migration and then prove it landed correctly. The cutover is the moment the new system becomes the source of truth, so treat it as a defined event with a start, a checklist, and a validation gate, not a background task you kick off and hope about. Freeze changes in the old system so no new data is created mid-move, take a final incremental backup or export of anything that changed since Step 4, then run the migration exactly as your clean test run did, using the same mapping.

Then validate, which is the step that catches the loss a smooth import can hide. Reconcile record counts between the old and new systems, spot-check a sample of records field by field against the source, and confirm the key totals your business relies on, the outstanding invoice balance, the active customer count, the open project list, match on both sides. Test the workflows and integrations you mapped in Step 1, not just the static records, because a feed into your accounting or reporting that silently stops is a failure even when every record is present. Only when validation passes do you point your team at the new system and open it for real work.

Watch out for skipping the rollback plan. Decide in advance what “failed validation” means and what you will do if you hit it, whether that is fixing forward or restoring from the backup and rescheduling, because deciding under pressure at 11pm on cutover night is how teams make the loss permanent. A cutover with a rollback ready is reversible; keep it that way until validation gives you a clear pass. Model an illustrative cutover window for your own data in the helper before you schedule the date.

Step 7: Train the team and decommission the old system

The data has moved, but the migration is not done until your team can work in the new system and the old one is retired safely. These two closing tasks are where the value of the whole effort is either captured or quietly lost. Start with training, because a new system nobody knows how to use is not an upgrade, it is a productivity hole. Show the team the workflows they run every day in the new tool, not a generic feature tour, and focus on the handful of tasks that make up most of their work, where a customer record lives now, how a report is pulled, how the daily flow they depend on happens here.

Then decommission the old system deliberately, which means slowly and only after you are sure. Do not cancel it on go-live day. Keep it available in read-only mode for a defined period, long enough to cover a full reporting or billing cycle, so that anything a later check turns up as missing can still be recovered from the source. Export a complete, permanent archive of the old system’s data in an open format and store it independently, because once the subscription ends that archive is your only record. Only after your team has worked in the new system without hitting gaps, and after that archive is safely stored, should you cancel the old subscription to stop paying for it.

Watch out for two opposite errors. One is decommissioning too early, cutting off the old system before validation and real use have confirmed the new one is complete, which is how the last copy of needed data gets lost. The other is never decommissioning at all, letting the old subscription run for months out of caution, which quietly doubles your cost. Set a retirement date, archive first, verify, then retire. Where the old contract has awkward exit terms, our SaaS negotiation walkthrough covers getting out cleanly.

How to sequence a software migration

The seven steps are not equal in effort or in risk, and knowing where the weight sits keeps you from spending your energy in the wrong place. The chart below shows where the effort in a typical migration actually lands: the bulk of it is in cleaning and mapping the data and in testing, not in the transfer itself, which is usually the quickest part. Teams that budget only for “the migration,” meaning the technical import, are budgeting for the small slice and starving the large ones, which is precisely why they run late and land with dirty data.

The risk is weighted differently again. The two steps that most often cause irreversible harm are the backup, because skipping it removes your ability to undo, and the validation, because skipping it lets silent loss go unnoticed until it is too late to trace. If you are short on time and must decide where to be most careful, be most careful there. The chart below shows an illustrative effort in days per phase for the worked example that follows, so you can see the same weighting in concrete shape before you plan your own.

Ways of migrating software data: import files, tools, and APIs

The steps above set the order; this section covers how the data physically moves, because that choice changes the effort and the failure mode even though it changes none of the safeguards. Five methods cover almost every business move, and most real migrations end up using two or three of them for different parts of the data.

Manual re-entry is the method nobody plans and plenty of teams end up doing for a slice of the data. Somebody opens both systems and types. It is slow and it introduces typing errors, but for a few hundred records, or for the awkward tail that no importer handles, it is often cheaper than building something clever. Use it deliberately for a defined subset, and never as the plan for the whole move.

A spreadsheet import against the target’s own template is the workhorse. You export from the old system into a comma-separated or spreadsheet file, reshape the columns to match the template, and load it. It is transparent, you can inspect exactly what is about to move, and you can rerun it after a fix. Its weak points are the ones described later on this page: encoding, date formats, commas sitting inside free text, and anything the template has no column for, which usually means attachments and relationships need their own pass.

A built-in migration tool, offered by the target vendor for a handful of common source systems, is the least work when it fits. It maps the standard fields for you and often carries more than a template will. The catch is that it decides what counts as standard, so custom fields and anything unusual can be dropped without a message, and its log reports its own success rather than your data’s correctness. A third-party migration service, or a vendor-assisted move, is the same trade at a larger scale and a price, and the validation still belongs to you.

An API transfer, written by a developer against both systems’ interfaces, is the option for large or complex moves, for anything that has to run in stages while both systems stay live, and for a migration you will repeat. It gives you full control over the mapping and lets you move data in batches so one bad batch does not force a redo, at the cost of real development time and a test cycle of its own.

Whichever method you choose, nothing in the seven steps changes. You still write the mapping document, still take the backup, still run the test on a copy, and still reconcile the result against the source, because every one of these methods can finish cleanly and still be wrong. Pick the method that fits the shape of your data, then hold it to the same validation.

Data migration: what breaks and how to validate it

Data migration is the part of the move that fails quietly. The import finishes, the progress bar completes, the new system looks populated, and the team declares the job done. Three weeks later somebody notices that every phone number lost its country code, that the closed tickets from last year cannot be searched, or that the attachment links on a thousand customer records point at nothing. None of those failures announce themselves at the moment they happen, which is why data migration needs a deliberate validation pass rather than a glance at a record count. Four places break far more often than the rest: the field mapping, the historical records, the attachments, and the reconciliation nobody schedules. Work through them in that order and most of the silent losses become visible while they are still cheap to fix.

Field mapping: where records quietly change shape

Most fields move without drama. Name goes to name, email goes to email, and nobody has to think about it. The damage lives in the handful of fields where the two systems disagree about what the data is. Watch for six recurring cases. Type coercion, where a date written one way is read another way, or a currency amount arrives as text and stops adding up. Truncation, where the target field is shorter than the source and the tail of a long note or address disappears without an error. Dropdown and status values that do not exist in the target, so records land on a default value or blank and your pipeline or ticket queue is quietly wrong. Required fields in the target that the source never captured, which either block the import or get filled with a placeholder that then looks like real data. Combined fields that must split, an address into street, city, and postal code, or a full name into first and last. And relationship fields, where a child record points at its parent through an internal identifier that changes on import, so the link breaks even though both records arrived.

Character encoding deserves its own mention because it is so easy to miss. Accented letters, currency symbols, and smart punctuation can survive an export and then arrive as replacement characters, and a comma sitting inside a free-text note can split a row in a comma-separated file so every field after it shifts one column left. The check is mechanical: export one record of every kind you hold, including the ugliest ones you can find, run them through the import, and compare the result to the source field by field. The mapping document you wrote in Step 3 is the specification you are testing against, so treat any difference between the document and the result as a defect in one or the other rather than something to shrug at.

Historical records and archives

Importers are usually built for the data a system needs to operate today, not for the history behind it. That is where the second class of breakage lives. Created and modified timestamps are the common casualty: many imports stamp every record with the date it was imported, which flattens your chronology and makes any trend report in the new system meaningless for the period before the move. Closed records can reopen because a status value did not map. Prior-year figures may arrive as a lump rather than as the transactions that produced them. And the audit trail, the record of who changed what and when, usually does not transfer at all, because most systems will not let an import write into their own audit log. That is a structural limit rather than a vendor failing, and pretending otherwise is how teams promise an auditor something they cannot deliver.

Decide the history question early, because it changes the scope more than any other single call. You have three honest options. Migrate the history into the new system and accept that some of its metadata will be reconstructed rather than original. Keep the old system read-only as the historical record for a defined period, which preserves everything exactly but costs a subscription. Or export a complete permanent archive in an open format and store it independently, which is cheap and durable but harder to search later. Many teams end up with a combination: recent history migrated because the team uses it daily, older history archived, and the old system kept readable long enough to answer questions during the transition. Where those archives need to stay findable, our document management verdict covers the storage side of the same problem.

Attachments, notes, and files

Attachments almost always move in a separate pass from the records they belong to, often through a different mechanism, and the link between file and parent record is the fragile part. The failures repeat across categories. Files above a size cap are skipped, sometimes without a message. Unsupported file types are rejected one by one while the import reports overall success. Files with identical names collide and one overwrites the other. Everything lands in a general file library with no connection to the customer, ticket, or project it belonged to. Permissions reset to whatever the target’s default is, which can quietly widen access to documents that were restricted. And images embedded inside notes break, because the note text migrated but the image it referenced did not.

Validate attachments as their own line item rather than assuming the record check covered them. Count files at the source and count them at the target. Open a sample from inside a record, not from the file library, so you are testing the link and not just the upload. Check one file that was deliberately restricted and confirm it is still restricted. There is a privacy dimension here too that is easy to overlook in the rush: a migration produces exports full of customer or employee files sitting on somebody’s laptop or in a shared drive. Keep those working copies encrypted, keep the list of who has them short, and delete them once validation passes, because a migration is one of the few moments a business voluntarily makes a complete copy of its own sensitive data.

A reconciliation checklist for the day after

Reconciliation is the step that converts a hopeful import into a verified one, and it takes a few hours rather than a few minutes. Run it before your team starts real work in the new system, and write down who checked each line, because a validation nobody signed is a validation nobody did.

• Record counts by type. Customers, invoices, tickets, projects, employees, each counted at source and target and matched. Investigate any gap, including a target count that is higher, which usually means duplicates were created rather than merged.
• Key business totals. The outstanding invoice balance, the active customer count, the open ticket queue, the current headcount. These are the numbers your business actually runs on, and they are the fastest way to spot a systematic error.
• Date range. Confirm the oldest and the newest record you expected are both present, and that created dates were not overwritten with the import date.
• A field-by-field compare of ten hard records. Not ten random ones. Pick the record with every custom field filled, the one with the longest note, the one with accented characters, the one with many attachments, the oldest, and the most recently edited.
• Relationship integrity. Open a parent record and confirm its children are still attached, then open a child and confirm it points back. Broken links are the most common invisible failure.
• Attachment count plus one opened file. Counted at both ends, with at least one file opened from inside a record to prove the link works.
• Dropdown and status values. Look for records sitting on a default or blank value in a field that should never be blank, which is the signature of an unmapped picklist.
• One rebuilt report. Rebuild a report you rely on in the new system and compare it to the same report from the old one for the same period. A matching report is stronger evidence than any number of spot-checks.
• Integrations and permissions. Confirm each connected system is sending and receiving, and that user access levels match what you intended rather than the target's defaults.

Keep the completed checklist with your mapping document. Together they are the record of what should have moved and the evidence that it did, which is what you will want in hand if a gap surfaces two months later and somebody asks whether it was ever migrated at all. If a line fails, treat it as a mapping-level problem until you have proved it is a one-off, because a single wrong record is usually a symptom of a rule that got a hundred of them wrong the same way.

Software migration by system type

The seven steps hold whatever you are moving, because the physics of a migration do not change with the category. What changes is which part breaks first. A CRM move usually survives the records and dies on the activity history. An accounting move usually survives the transactions and dies on the chart of accounts. Knowing your category’s weak point tells you where to spend the extra day of testing, and it is the difference between a validation that looks thorough and one that actually catches something. The sections below name the pressure point for four common categories, and the section after them handles regulated and vertical systems separately, because there the binding constraint is not technical. Categories with their own buying pages here, such as a point of sale system or an inventory system, are chosen on those pages and moved with the steps on this one; the mechanics do not change with the category. Size the effort for your own inputs in the helper on this page, and price the new subscription itself in our true-cost calculator so the money and the effort are planned together rather than one at a time.

CRM migration

The records are the easy part of a CRM migration. Contacts and companies move cleanly in most cases, and a team that only checks those will report a clean result. The value in a CRM is the relationship history hanging off those records: the calls, emails, notes, and meetings that tell a salesperson what happened last time. That history is stored differently in every system, it is bulky, and it is the thing importers most often leave behind or flatten into a single undated blob. Decide before you start whether history migrates for every account or only for active ones, because carrying five years of activity for dormant contacts is a large cost for very little use.

Three other CRM specifics deserve attention. Pipeline stages rarely map one to one, so agree the stage translation with the people who work the pipeline rather than deciding it alone, and check afterward that the deal values landed in the stages you expected rather than bunching on a default. Record ownership needs an explicit rule, because an import that assigns every account to the administrator who ran it destroys the assignment logic your team works from. And duplicate handling cuts both ways: the target’s own deduplication rules can merge two genuinely different contacts who share an email, so review merges rather than trusting them. Our CRM buying walkthrough covers the selection that precedes this, and our CRM cost verdict the money, including the free versus paid comparison if the move is to or from a free tier.

Accounting and ERP migration

Accounting is the category where timing matters most. Migrating in the middle of a period leaves you reconciling two half-books, so the natural cutover points are a period end or, better, a financial year end, when balances are already being closed and checked. The mapping problem here is the chart of accounts. Two systems almost never structure accounts identically, and a chart that grew organically over years usually contains accounts nobody has posted to since the person who created them left. The migration is the right moment to rationalize it, but do that as a deliberate exercise with whoever prepares your accounts, not as a side effect of the import.

Then decide how much history you carry. Opening balances plus open items, meaning unpaid invoices, unapplied credits, and outstanding bills, is the lighter move and is enough to operate. Full transaction history is heavier and often arrives with reconstructed dates. Whichever you choose, reconcile to the trial balance on both sides before you trust anything, because in accounting a mismatch is not a cosmetic issue. Tax codes and bank feeds both need explicit attention: tax settings rarely map automatically, and bank connections have to be re-established and re-linked in the new system rather than migrating. Be careful with one thing above all. How long you must retain accounting records, in what form, and what has to remain reproducible is set by tax and company law that varies by country and entity type, and it is not something a buying walkthrough can settle for you. Confirm retention and record-keeping with your accountant and the relevant tax authority (for a US business, the IRS’s page on how long to keep records) before you archive or delete anything. Our accounting software walkthrough and accounting cost verdict cover the choice itself, and our bookkeeping service verdict the option of handing the work over.

HR and payroll migration

HR and payroll is the category with the least tolerance for error, because a mistake lands in someone’s pay packet and in their trust. Two structural rules make it safer. First, migrate at a period boundary, ideally a payroll year boundary, because year-to-date figures are the hardest thing to carry mid-year and the easiest to get subtly wrong. Second, this is the clearest case for a short parallel run: process one or two full cycles in both systems and reconcile the outputs line by line before the old one stops. Everywhere else in this walkthrough a parallel run is optional; here it earns its cost.

The data itself needs care beyond the mapping. Employee records carry history that matters, including start dates, contract changes, and leave balances that people will notice immediately if they arrive wrong. Benefit and deduction settings often have to be rebuilt by hand rather than imported. And the sensitivity level is higher than any other category, so restrict who touches the export files, keep them encrypted, and delete working copies once validation passes. On the obligations side, be honest about the boundary: payroll filing, reporting, and record-retention duties depend on your jurisdiction, your workforce, and your scheme, so confirm them with your payroll provider, your accountant, and the relevant tax authority (for a US employer, the IRS’s employment tax recordkeeping page) rather than inferring them from a walkthrough. Our HR software walkthrough, HR software cost verdict, and payroll cost verdict cover the surrounding decisions.

Help desk migration

A help desk migration has one moment that is genuinely all-or-nothing: the support email address. Until it points at exactly one system, you have either duplicate tickets or lost ones, and neither is visible from inside the new tool. Plan that switch as its own micro-cutover with a named owner, test it by sending mail from an outside address, and confirm that nothing is still landing in the old queue afterward. Everything else in a help desk move can be corrected at leisure; a mail loop cannot.

The rest of the category has its own recurring gaps. Ticket threading is easy to lose, so conversations arrive as disconnected messages rather than a readable exchange, which is exactly what an agent needs when a customer returns with an old problem. Requester identity has to match, or one customer becomes three contacts with three histories. Macros, canned replies, and automation rules almost never migrate and are usually rebuilt, which is a real cost worth budgeting. Service level definitions and their clocks need rethinking rather than copying, because two systems measure response and resolution differently. Knowledge base articles bring a web problem with them: if the old articles were public and indexed, the new URLs need redirects or you lose the traffic and the links. And satisfaction history is worth carrying if you report on it over time, which our survey software walkthrough touches on. Our help desk cost verdict covers per-agent pricing for the move itself.

How to migrate to new QMS software and other regulated systems

Generic migration advice assumes the records are data. In a quality management system, a practice management platform, a payroll system, or a controlled document system, the records are evidence, and that one difference changes the scope, the sequence, and what counts as finished. The seven steps above still hold: you still audit, scope, clean, map, back up, test, cut over, validate, and retire. What changes is that the result has to satisfy somebody outside your team, and that question is settled by an auditor, a registrar, or a regulator rather than by a clean import log. This section covers what the generic version of the advice gets wrong, because that is where teams migrating a QMS get hurt.

Start by naming what the move has to preserve, because it is a longer list than a normal inventory. A quality management system holds controlled documents together with their revision history, so you can still establish which version was in force on a given date. It holds approval and signature records, and the link between an approval and the exact version it approved. It holds training records and their connection to document versions, change control history, nonconformance and corrective action records with the links tying a finding to its investigation and its closure, and supplier, equipment, and calibration records. Above all it holds traceability, the chains that connect a record to the document, the person, and the moment behind it. Any of those chains that a migration cannot carry is a scope decision, not a detail.

What generic migration advice gets wrong here

Four assumptions that are harmless in a normal move become expensive in a regulated one. The first is that the current state is the record. In a controlled system the current version of a document is only part of it; the record is the version, the revision that preceded it, the approval that released it, and the training tied to that specific revision. The second is that history can be archived cheaply. A flat export preserves the values and loses the links, and the links are usually what somebody asks to see. The third is that a successful import is a working system, when in a controlled environment the new system may need documented evidence that it does what it is meant to do before it holds anything. The fourth is that the cutover date is yours to choose, when a certification visit, a reporting period, or an inspection window can decide it for you.

The practical consequence is that the plan gets one extra step at the front, before the Step 1 audit: establish what you are actually required to preserve, produce, and prove. Everything downstream, scope, retention, the shape of the archive, and whether a parallel run is optional, falls out of that answer. Doing it in the other order, migrating first and asking afterward, is how a move becomes unpickable.

Record retention obligations set the scope before you do

In a normal migration you decide what history to carry. In a regulated one, part of that decision has already been made for you, and the useful move is to find out where the line sits before you scope anything. Retention is not one question but four: what has to be kept, in what form, for how long, and who has to be able to produce it. A system that keeps the values but cannot show who approved a document on a given date may satisfy the first and fail the fourth.

This walkthrough cannot tell you what your obligations are, and any page that gives you a number for them is guessing. Retention periods and record-keeping duties depend on your sector, your jurisdiction, the standard or scheme you are certified or registered under, the scope of your own quality system, and sometimes on contracts you have already signed, and they change over time. Get the answer from your own quality function, your registrar or notified body, your regulator, and where money or employment records are involved, your accountant. Then write it into the migration plan as a scope line, because it is the input that decides how much of the old system you can ever retire. Where controlled documents are the bulk of what you hold, our document management verdict covers the storage and versioning side of the same problem.

Validation and the audit trail after cutover

The structural difficulty is the audit trail. Most systems will not let an import write into their own audit log, which means migrated history arrives as data stripped of its original trail, with every entry stamped as created by the import on the day it ran. That is a limitation of how these systems are built rather than a mapping mistake you can fix, and it is the single most important thing to understand before you commit to a plan. In the new system, the trail starts at go-live. Anything before that lives wherever you decided to put it.

Validation after cutover is the other half. In a controlled environment, the reconciliation described earlier on this page is not just good practice, it is potential evidence, so run it as a documented activity: write down the checks in advance, record the result of each one against the record counts and totals you took from the source, name the person who performed each check, and date it. Keep the mapping document, the test migration results, and the completed reconciliation together, because that package is the account of what moved and why you believe it moved correctly. Whether your new system additionally needs a formal validation exercise before it holds controlled records, and what that exercise has to contain, is a question for your quality function and your auditor, not for a buying walkthrough.

Why you cannot simply archive the old system

The tempting shortcut is to export everything, cancel the old subscription, and treat the archive as the historical record. It often does not work here, for reasons worth knowing before you budget the move. An export usually flattens relationships, so the connection between an approval and the exact version it approved, or between a training record and the revision it covered, may survive as two files rather than as a link. Signature and approval metadata frequently does not export at all. A proprietary export format can be unreadable in a few years without the software that wrote it. And an archive answers what a record said far better than it answers who saw it, who approved it, and when.

That leaves three honest options, and most teams end up combining them. Migrate the history into the new system and accept that some of its metadata is reconstructed rather than original. Keep the old system readable, in read-only mode, for a defined period, which preserves everything exactly and costs a subscription. Or retain a complete, verified export in an open format as the historical record, which is cheap and durable but harder to interrogate. The choice has a real budget consequence: in a regulated move you may pay for the old system for considerably longer than the few billing cycles Step 7 suggests, so put that in the plan rather than discovering it at renewal. When the day does come to switch it off, our cancellation walkthrough covers doing it cleanly, and our SaaS spend audit walkthrough is the exercise that catches an old system nobody remembered to retire.

Run in parallel through at least one full cycle

Everywhere else on this page a parallel run is optional, and the read-only old system does most of the same work for none of the double entry. In a regulated or high-consequence system it earns its cost, because the evidence you want is not that the records arrived but that the system produces the same result as the one it replaces. Run at least one complete cycle in both, a full payroll run, a reporting period, a document review round, or an audit-relevant process end to end, and reconcile the outputs line by line rather than sampling them.

Time-box it in writing before it starts. Name the number of cycles, state which system is authoritative for each kind of data during the run, put the reconciliation date on the calendar, and define what a passing reconciliation looks like. The failure mode is the parallel run that never ends, where nobody declares the new system authoritative and the business operates on two half-trusted datasets, which in a controlled environment is worse than either system alone. Set the flag in the helper on this page to a regulated system and the readiness score drops accordingly, which is the point: the same data is a heavier move when it has to carry evidence.

Vertical systems: practice management and industry platforms

Vertical software concentrates the same problems in a different way. A practice management platform, whether it runs a veterinary practice, a clinic, a law firm, or a workshop, is really several systems sold as one, so migrating veterinary practice software or switching any practice system moves appointments, client and patient or matter records, service or clinical notes, billing and payments, inventory, documents, and automated reminders in a single project. Treat each of those as its own inventory line in Step 1, its own mapping in Step 3, and its own reconciliation line in the validation, because a check that confirms the client list arrived says nothing about the reminders.

Two things break more often here than in a generic move. The first is the relationship model. A client owns several patients, matters, or sites, each with its own history, and a target that flattens that into a single contact list has lost the structure the practice actually runs on, even though the record count reconciles perfectly. Check the relationships explicitly, from parent to child and back. The second is anything recurring. Reminder schedules, recalls, repeat billing, and follow-up rules are usually rebuilt in the new system rather than imported, which is real work to budget, and their absence is invisible until the day the reminders stop going out. Add a line to the validation checklist that confirms the next scheduled reminder actually exists in the new system, and where your profession carries its own record-keeping duties, confirm them with your professional body rather than inferring them from a general walkthrough.

Migrating software: parallel running vs a hard cutover

When migrating software, one structural decision shapes the whole final phase: do you switch in a single hard cutover, or run the old and new systems side by side for a period before retiring the old one? The seven steps above describe a hard cutover, freeze, migrate, validate, switch, because for most small and mid-sized teams it is the simpler and, done with a backup and a test behind it, the safer path. There is one moment of change, one source of truth at all times, and a short, planned window where the risk is concentrated and managed. Its weakness is that it depends entirely on the safeguards: without a verified backup and a clean test run, a hard cutover is a leap.

Parallel running keeps both systems live for a defined period, with the team either entering new work in both or working in the new system while reconciling its outputs against the old one. Its strength is proof: for data that drives payroll, invoicing, or compliance reporting, running one or two full cycles in parallel and confirming the two systems produce matching results is evidence a spot-check cannot match. Its costs are real, though. Every record entered twice is doubled work, the two systems drift apart the moment someone updates one and not the other, and the team is paying for both subscriptions while it happens. The failure mode is the open-ended parallel run, where nobody ever declares the new system authoritative and the business limps along with two half-trusted datasets.

A reasonable rule: choose a hard cutover with full safeguards for most moves, and add a short parallel period only where an output error would be expensive or regulated, such as a payroll run or a tax filing, which the section above on regulated and vertical systems sets out in more detail. If you do run in parallel, time-box it in writing, one or two cycles at most, define which system is authoritative for each kind of data during the run, and put the reconciliation on the calendar so the period actually ends. The read-only old system that Step 7 prescribes already gives you most of a parallel run’s safety with none of the double entry, which is why it is the default in this walkthrough.

Worked example: a team migrates to new software

Consider a small business, an eighteen-person company moving its customer and project data from an older tool it has outgrown into a new platform it chose after a proper trial, running the migration through all seven steps with illustrative numbers so the process is concrete. Every figure here is illustrative and internally consistent; your own numbers will differ, and the specifics of any tool’s import should be confirmed directly.

In Step 1 they audit and find more than they expected: roughly five thousand customer records, a few thousand projects, plus attachments, a handful of custom fields added over the years, and a feed into their accounting system. They mark the active records and the current year’s projects as must-migrate, archive three years of closed projects to a separate export, and leave a pile of obvious duplicates behind. In Step 2 they scope firmly to active data plus the current year, and schedule the cutover for a quiet weekend well clear of month-end. In Step 3, the longest phase at an illustrative six person-days, they dedup the customers, standardize the phone and date formats, split a combined address field, and write a mapping document that gives every custom field a home in the new system.

In Step 4 they take a full export, verify the record counts and that attachments are inside it, and store a copy on independent storage. In Step 5 they run a test migration of a real slice into a trial workspace, discover that one custom field and the attachments were silently dropped, fix the mapping, and run it again until a test comes through clean. In Step 6 they freeze the old system on Saturday morning, take a final incremental export, run the real cutover, then reconcile the customer count and the open-project list against the source and confirm the accounting feed still flows before opening the new system Monday. In Step 7 they train the team on their daily workflows, keep the old tool read-only through the next full billing cycle, store a permanent archive, and only then cancel. The move lands boring and complete, which is exactly the goal.

The numbers reconcile as follows, and they are the same numbers the helper on this page produces from the same inputs: five thousand records, mixed cleanliness, a few connected systems, and a standard business system rather than a regulated one. Preparation is three person-days to audit and plan, six to clean and map, and four to back up and test, so thirteen person-days before anyone touches the live system, which is what the helper reports as illustrative prep effort. The cutover window itself is short by comparison: the freeze, the final export, the transfer, and the first reconciliation pass run in roughly three and a half hours on the Saturday morning, which is the window the helper sizes. The remaining validation, the Monday checks, and the training and decommission work make up the last five person-days on the effort chart above, for eighteen person-days in total. The helper puts this shape at a readiness score of 77, which lands in the band that says to clean and map before touching the new system, and that is exactly where the team spent its longest phase. Model your own version in the helper on this page.

What a software migration plan should contain

A software migration plan is short. It is a few pages, not a project management artifact, and its whole purpose is to settle in advance the decisions you do not want to be making at eleven at night with a half-finished cutover in front of you. Teams skip it because it feels like ceremony, then rediscover why it exists when nobody can say whether a validation failure is bad enough to roll back. Write it after Step 2 and revise it after Step 5, because the test migration nearly always changes something in it.

• Scope. What migrates, what is archived outside the new system, and what is deliberately left behind, item by item from the Step 1 inventory.
• Inventory and counts. Rough record counts per data type, plus the hidden data: attachments, custom fields, historical archives, and the integrations feeding in or out.
• The field mapping document. Referenced rather than repeated, but named, dated, and owned by someone.
• The backup. Where it is, what format it is in, who verified it was complete, and when.
• Test criteria. A written definition of a clean test migration, so the decision to proceed is a comparison against a standard rather than a feeling.
• The cutover window. The date, the start and end times, who is running it, and who is told in advance.
• The validation checklist. The reconciliation list from earlier on this page, with a clear pass or fail on each line and a name against each check.
• The rollback trigger. Which failures send you back, who makes that call, and the time by which the call must be made.
• Training and decommission. Who is trained on what, and the date the old system goes read-only and the later date it is cancelled.

One person should own the plan and one person should own the cutover, and they can be the same person on a small team. What matters is that both roles are named rather than assumed, because the failure mode of a shared cutover is a group of people each waiting for someone else to decide. Circulate the plan before the window rather than during it, and give anyone who will be affected a chance to say that the timing collides with something you did not know about. Price the whole switch, the new subscription and the old one running in parallel, in our true-cost calculator, and if the move is part of a wider cleanup, our SaaS spend audit walkthrough is the companion exercise.

Common mistakes when migrating software data

The same handful of mistakes sink most software migrations, and nearly all of them come from treating the move as a single import rather than a sequence with safeguards.

• Migrating dirty data. Copying duplicates, gaps, and inconsistent formats into the new system just relocates the mess and makes it harder to fix once it is tangled up with the new tool. The migration is your one natural cleaning checkpoint, so clean before you move, not after.
• Skipping the backup. Starting a migration with no verified, independent backup turns a recoverable problem into a permanent one. Without a clean original to restore from, a failed cutover has no undo, which is the difference between a bad evening and a lost dataset.
• No test migration. Going straight to a live import means discovering every mapping error and dropped field in production, with your team already trying to work. A test run on a copy finds those problems while fixing them is still free.
• Trusting a smooth import. An import that finishes without an error can still have dropped a field or reformatted every value. The check is not whether it ran but whether the data is correct, which only a real validation against the source can tell you.
• Forgetting the hidden data. Attachments, custom fields, historical archives, and the feeds into other systems are exactly what generic importers skip. If your inventory in Step 1 missed them, your migration will too, and you will find out at the worst time.
• Decommissioning too early. Cancelling the old system on go-live day, before validation and real use have confirmed the new one is complete, is how the last copy of needed data disappears. Keep the old tool read-only and archive it before you retire it.

Troubleshooting: what to do when a migration gets complicated

Even a careful migration runs into harder cases. Here are the common ones and what to do about each.

Your data is spread across several connected systems. When more than one tool feeds the data you are moving, the risk is not just the records but the connections between them, so map the integrations as carefully as the fields. Decide which system becomes the new source of truth, migrate in a sequence that keeps the feeds consistent rather than all at once, and test each connection in the sandbox before cutover. Multi-system moves are where scope creep is most dangerous, so hold the line you set in Step 2 and consider migrating in phases, one system at a time, rather than attempting a single big-bang cutover that has many more ways to fail.

Your dataset is very large. When a full pre-clean of every record is impractical, prioritize instead of trying to do everything. Clean and validate the high-value, actively-used records thoroughly, and archive or defer the long tail of old data to a separate export you can import later or keep for reference only. A large migration also takes longer to run, so time your test to measure the real duration and size the cutover window to match, and consider running the transfer in batches so a problem in one batch does not force you to redo the whole thing.

The vendor offers to do the migration for you. A vendor-assisted or “white glove” migration can genuinely save effort, but it does not remove your responsibility to validate the result. The vendor’s tool measures its own success, not the correctness of your data, and it will not know which custom field or archive matters to your work. Give them your mapping document and inventory, then run your own validation on what they deliver exactly as you would on your own import: reconcile counts, spot-check records, and confirm the workflows. Treat the assistance as help with the labor, not as a reason to trust the outcome unchecked.

Something is missing after cutover. This is precisely why you kept the backup and the old system read-only. If validation, or a user a week later, turns up missing or wrong data, do not panic and do not start manually re-entering blindly. Go back to the source in the old system or the backup, confirm what the correct value was, work out whether the gap is a mapping error affecting many records or a one-off, and fix it at the mapping level if it is systematic. Because you kept the original readable, a gap found after cutover is a repair, not a loss, which is the entire reason the earlier steps insisted on backups and a slow decommission.

How to plan a rollback for a software migration

Every migration of software needs a written rollback plan before the cutover, not a vague intention to “go back if it fails,” because the middle of a failed cutover is the worst possible moment to design one. A rollback plan is short, and it answers four questions in advance. What triggers it: define which validation failures actually send you back, a mismatch in record counts or key totals, a broken integration your business depends on, versus the cosmetic issues you would fix forward. Who decides: name the one person who makes the call, because a committee debating at the end of a cutover window defaults to pushing ahead. When the decision happens: time-box the validation so there is a moment, before the team starts real work in the new system, where the result is either passed or rolled back. And how it physically works: because you froze the old system rather than dismantling it, rolling back means unfreezing it, telling the team it is live again, quarantining the partial data in the new system, and rescheduling the cutover once the cause is fixed.

The reason rollback planning belongs before go-live is that a rollback gets more expensive by the day afterward. In the cutover window itself, going back costs almost nothing: the old system is intact and no new data exists anywhere else. A week later, real records live only in the new system, and going back means exporting that delta and re-entering it into the old tool, which is messy enough that most teams fix forward instead. That steep curve is exactly why Step 6 validates inside the window rather than trusting that problems will surface gradually. The test migration in Step 5 doubles as your rehearsal: you already know how long the import takes and what a clean result looks like, so a failed live run is recognizable within hours, while the rollback is still nearly free.

Your software migration checklist

Use this as the save-this asset. Work top to bottom, and do not let the timeline pressure you into skipping the safeguards.

• Audited the data and workflows, listing every kind of record, its rough count and cleanliness, the hidden data (attachments, custom fields, archives), and the integrations, each marked must-migrate, archive-only, or leave-behind.
• Scoped and scheduled exactly what moves, what gets archived, and what stays behind, with a cutover date in a genuinely quiet window and real time given to cleaning and testing.
• Cleaned the data, removing duplicates, filling or flagging gaps, and standardizing formats, so the mess does not move with the records.
• Mapped every field from the old system to the new one in a written document, with an explicit decision for anything that has no obvious home.
• Backed up everything in a restorable format, verified the export is complete, and stored a copy independent of both systems.
• Ran a test migration on a real slice of data, checked the results against the source, and repeated until a test came through clean.
• Executed the cutover in the planned window with a rollback ready, then validated live data by reconciling counts, spot-checking records, and confirming key totals and integrations.
• Trained the team on the real daily workflows in the new system, not a generic tour.
• Decommissioned deliberately, keeping the old system read-only through a full reporting cycle, storing a permanent archive, and only then cancelling the subscription.

When to revisit your migration plan

A migration plan is not a document you write once and follow blindly, because what you learn in the test almost always changes the plan. Treat the test migration in Step 5 as a checkpoint to revisit scope and timeline: if the test reveals more dropped fields, dirtier data, or a longer run time than you assumed, adjust before the cutover rather than pushing ahead on a plan the evidence has already contradicted. It is far cheaper to move the cutover date by a week than to discover mid-cutover that the timeline never fit.

Revisit sooner if any of three things change. Your scope grows, because a stakeholder realizes a system or archive you meant to leave behind actually matters, in which case re-scope deliberately rather than bolting it on at the end. The test keeps failing in the same place, which usually means a data-quality problem at the source that needs fixing before any transfer, not another attempt at the import. Or your timeline collides with a busy season or reporting period you underestimated, in which case moving the cutover is almost always cheaper than forcing it. The point of planning the migration in steps is that each step is a chance to catch a problem while it is still cheap to fix, so use them that way. Run your own inputs through the helper on this page whenever the shape of the move changes, so the effort estimate stays honest.

The bottom line

Migrating to new software is not really a technical task, it is a discipline of order and reversibility. The teams that switch systems cleanly are not the ones with the best import tool; they are the ones who audited what they had, scoped the move honestly, cleaned and mapped the data before it went anywhere, backed everything up, tested on a copy until it came through clean, validated the live result field by field, and retired the old system slowly instead of on go-live day. Every one of those steps exists to answer a single question: if something goes wrong, can you get your data back? When the answer stays yes from the first backup to the final decommission, the migration is a managed project. When the answer is no, it is a gamble with your business’s records. Do the unglamorous steps in the right order and the switch lands quietly and complete, which is exactly what a good migration should feel like. Size your own move in the helper on this page before you set a cutover date, and let the plan, not the deadline, decide when the data moves.

VetLoft works for buyers and never for vendors, and this walkthrough reflects that: it is educational material, not technical, legal, or data-protection advice, and no step or figure here is a rule for your specific systems. A safe migration depends on your data, the tools involved, your integrations, and your obligations, all of which differ from one business to the next. Back up your data independently before you move it, confirm each tool’s current import and export behavior directly, and where records carry legal, tax, privacy, or quality-system weight, confirm the handling, retention, and validation requirements with a qualified professional, your own quality function, and the regulator or registrar that oversees your sector. Every number in these pages is illustrative and included to show the method, not to predict your result, so validate against your own systems before you rely on any of it.