Data Migration for a Small Business: Moving to a New System Without Losing Any Data

TL;DR: A small business can finish a data migration without losing data if the move is a process, not an event. Back up and prove the restore, name an owner for every kind of record, clean and de-duplicate first, map every field, rehearse on a copy, match the counts to the record, and keep a practiced way back.

Data migration for a small business usually starts with good news. You picked the new system: the CRM, the practice management software, the ERP, the scheduling tool. Then someone asks the quiet question. How do ten years of customers, invoices and notes get from the old system into the new one, intact?

The data is the part you cannot buy again. Here is the data migration checklist I use, in order, with the federal guidance behind each step.

Why do data migrations go wrong?

The auditors who watch the biggest projects say it plainly. In a May 2026 report on Homeland Security's financial systems, the U.S. Government Accountability Office wrote that "data conversion and migration are complex and difficult tasks. Further, converting data incorrectly can have long-term repercussions." (GAO-26-107863, May 2026)

A bad data migration rarely fails loudly on day one. It shows up in March, when a customer's balance is wrong.

The best public example is a bank. In April 2018, TSB in the United Kingdom moved its customer data to a new platform. The Financial Conduct Authority's account of what happened next is worth reading twice: "While the data itself migrated successfully, the platform immediately experienced technical failures." A significant proportion of TSB's 5.2 million customers were affected, and it took until December 2018 to return to business as usual. UK regulators fined the bank £48.65 million and said it "failed to organise and control the IT migration programme adequately." (FCA, December 2022; Bank of England, December 2022)

The data arrived. Customers still could not bank. A data migration is finished when people can do their jobs in the new system, and you could still go back if they could not.

The other way a data migration goes wrong is the data itself. A survey of duplicate record research in IEEE Transactions on Knowledge and Data Engineering explains why old data is rarely clean: "Errors are introduced as the result of transcription errors, incomplete information, lack of standard formats, or any combination of these factors." (Elmagarmid, Ipeirotis and Verykios, 2007)

What is the data migration checklist for a small business?

Nine steps. The federal government uses the same shape for its own moves: GAO's leading practices split a data migration into "three different phases for data conversion activities: pre-conversion, cutover, and post-installation." Steps 1 to 6 are pre-conversion, 7 and 8 are cutover, and 9 is everything after.

1. Back up first, and prove the backup restores

Before anyone exports, maps or deletes anything for the data migration, take a full backup of the old system and restore it somewhere else. Open it. Look at real records.

NIST's contingency planning guide says "system data should be backed up regularly" and that backup media "should be tested regularly to ensure that data are being stored correctly and that the files may be retrieved without errors or lost data." (NIST SP 800-34 Rev. 1) Your restored copy is also the safest place for every data migration trial run in step 6.

2. List every kind of data, where it lives and who owns it

Make a one page inventory before the data migration starts. For each kind of record (customers, jobs, invoices, products, notes, attachments, employee files), write three things:

• Where it lives today. The main system, plus the spreadsheets, shared folders and inboxes around it.
• Who owns it. One person who can say what a correct record looks like and sign off that it moved.
• How much there is. A count you write down now. You will need it in step 7.

If the real customer list is a spreadsheet on the office manager's desktop, that spreadsheet is the source.

3. Decide what the data migration leaves behind

Not everything should come along. My wife Amelia, Kief Studio's co-founder and CEO, makes the case well in the cheapest way to protect data is to not keep it (opens in a new tab). Every record you leave behind is one less for the data migration to clean, map and check.

Write the rules down per kind of record: move it, archive it read-only, or dispose of it on schedule. MyRHC keeps a plain reference on data retention and secure destruction (opens in a new tab) if you want a starting point, and your accountant and counsel decide the periods that apply to you.

4. Clean and de-duplicate before you move, not after

Fix the data in the old system, or in a cleaned copy, before it goes anywhere. GSA's playbook for federal system migrations puts the lesson in one line: "Start data cleansing early and prior to implementation; continue throughout to ensure readiness." (GSA M3 Playbook, activity 3.13) GAO's version adds that you set "criteria for cleansing data" first, so cleanup is a rule, not a mood.

Duplicates deserve their own pass, and the research on them is humbling. A peer-reviewed study of electronic health records at five healthcare organizations found that the same first and last name belonged to two or more people in 16.49% to 40.66% of records. Adding date of birth cut that to between 0.16% and 15.47%. (McCoy and colleagues, BMJ Quality and Safety, 2013) A 2025 study of about 1.2 million patients at one academic medical center found 2.9% had duplicate records, and that people with missing details at first registration were more likely to have them. (Sahin and colleagues, Applied Clinical Informatics, 2025)

The lesson carries to a data migration for a contractor's customer list or a dental office's patient file:

• Never merge two records on a name alone. Match on at least two more things, such as phone, email, address or date of birth.
• Have a person review every proposed merge before it happens, and keep a list of what was merged into what.
• Fix the form that let the duplicate in.

5. Map every field, and decide about the leftovers

Build a simple table for the data migration: old field, new field, any change on the way (date formats, phone formats, status codes), and who approved it. Every old field gets a row.

Fields with no home are where data quietly disappears: the custom "notes 2" field, the checkbox that marks tax-exempt customers. Each gets a decision: map it, archive it, or drop it on purpose.

6. Rehearse the whole move on a copy

Run the full data migration at least once on a copy of the data, into a test copy of the new system, start to finish, with a stopwatch. GAO calls this a mock conversion, "a dress rehearsal of the conversion activities required when converting data into a new system." FEMA plans three of them for its own financial system move. (GAO-26-107863)

A small business data migration needs one, and a second if the first surprised you. It tells you how long cutover takes, which fields break, and whether the counts in step 7 match.

7. Reconcile: counts, totals and spot checks

GAO's standard is clear: staff "should reconcile data in the legacy system to the new system and document where adjustments are made to converted data." In practice, for a small business data migration, that means three checks, written down before the move with the numbers you expect:

1. Counts. Customers, open jobs, products, invoices. Old count, new count, and an explanation for every difference (for example, 37 duplicates merged on purpose).
2. Totals. Open receivables, unpaid bills, inventory value, to the cent. Money is the fastest way to catch a dropped or doubled row in a data migration.
3. Spot checks. Pick 25 records at random and 10 you know are odd: the customer with three locations, the oldest open invoice, the record with the longest notes. Open each one in both systems side by side.

8. Cut over with a go or no-go time and a way back

GAO's cutover practice asks for a "backup plan in case the new system fails to operate as expected," and for management to make "a go/no-go decision before go-live" with criteria set in advance. For a small business data migration, that fits on one page:

• The day and time of the move, and who is on hand.
• The freeze: when people stop entering data in the old system.
• The reconciliation numbers from step 7 and what they must be.
• The go or no-go time. If the checks have not passed by then, you stop.
• The way back: the exact steps to return to the old system, practiced once during the rehearsal.

Before the data migration, decide how much downtime and how much recent data you can afford to lose; our note on recovery time and recovery point objectives explains both in plain words.

9. Keep the old system read-only, then retire it properly

After cutover, do not switch the old system off. Make it read-only, so nobody can change it, and keep it available while people find the things the data migration missed. In my experience, someone usually needs to look up an old record in the first weeks, and the answer should be "open the old system," not "restore a backup."

GAO's post-installation steps include "post-conversion data cleanup" and deciding "how legacy data are to be archived." Set a date for both. When the old system finally goes, the data on its disks still needs handling. NIST's media sanitization guide defines sanitization as a process that "renders access to target data on the media infeasible for a given level of effort," and it covers media "before disposal, reuse, or leaving the effective control of an organization." (NIST SP 800-88 Rev. 2, September 2025)

What does a data migration cost a small business?

There is no reputable published price range for small business data migration, so I will not invent one. What I can give you is what moves the price of a data migration, so you can read a quote:

• How dirty the data is. Duplicates, free text where dates belong and missing fields add hours to every step after this one.
• How many sources. One database is one job. One database plus four spreadsheets and a shared inbox is five.
• Attachments and history. Moving the current balance is easy. Moving every past transaction, file and note with its dates is real work.
• Undocumented rules. Fields that mean something only one person remembers take time to discover.

Before you sign with the new vendor, check how you would get your data back out; our note on vendor lock-in covers it. Today's destination is the source of a future data migration. I also checked what happens to your data when you cancel software (opens in a new tab) for eight common tools.

What should a Massachusetts business watch during a data migration?

Most state rules that touch a data migration are about personal information, and they apply to businesses of every size in Worcester, Shrewsbury and across Central Massachusetts.

• Exports on laptops and drives. A data migration creates copies: CSV exports, files on a USB drive, a spreadsheet emailed to the new vendor. The state's data security regulation calls, to the extent technically feasible, for "encryption of all personal information stored on laptops or other portable devices" and of records that "travel across public networks." (201 CMR 17.04) Keep exports encrypted, in one known place, and delete them when the move is done.
• Disposing of the old system. Massachusetts law says electronic media containing personal information "shall be destroyed or erased so that personal information cannot practicably be read or reconstructed." (M.G.L. c. 93I, section 2) That includes the retired server and old office PCs if they hold personal information. I wrote a separate guide to disposing of old business computers in Massachusetts (opens in a new tab), including the proof to keep.
• Payroll history. Massachusetts requires employers to keep payroll records "for at least 3 years after the entry date of the record." (M.G.L. c. 151, section 15) Federal wage rules set the same three year floor. (29 CFR 516.5) If the new payroll system starts fresh, the old history has to stay readable somewhere for at least that long.

Regulated fields add stricter rules; see our note on compliance data integrity in regulated industries.

Which company is best for data migration?

The one with the best plan for your data migration. Ask any provider, including us, to answer these in writing before you sign:

1. How will you back up the old system, and when will we see a test restore?
2. Who on our side owns each kind of record, and what do they sign off on?
3. What are the cleanup rules, and how are duplicates matched and approved?
4. Can we see the field map, including fields with no home in the new system?
5. How many rehearsals on a copy, and what did the last one show?
6. Which counts, totals and spot checks prove the move worked?
7. What is the go or no-go time, and what exactly happens if we go back?
8. How long does the old system stay available read-only, and how is it retired?

A data migration provider who answers all eight clearly is worth talking to, whatever its size. If you want a deeper read on the ownership side, Amelia's piece on where to start with data governance (opens in a new tab) pairs well with question 2.

This article is general information, not legal advice. Kief Studio is not a law firm, and reading it does not create an attorney-client relationship. Laws and regulations change, so check the current text and talk with a licensed Massachusetts attorney about your situation.