Data Migration Checklist: Moving Client and Project Records Safely

Before You Touch an Export Button

The migrations that go badly almost always skip this step. Someone opens the old system, hits export on the clients table, and starts mapping fields into the new one the same afternoon. Six weeks later they discover the export was pulled on a Tuesday and three new deals closed on Wednesday never made it across.

Fix the timing problem first. Pick a freeze date and communicate it: after that date, nobody creates a new client, project, or invoice in the old system. Anything urgent gets logged in a shared doc and entered manually into the new platform after cutover. This sounds like overkill for a 15-person agency. It is not. The freeze date is what turns migration from an open-ended chase into a task with a defined edge.

Second, decide who owns the decision on data quality, because someone will ask "do we really need to fix this contact's title before importing it" fifty times over the course of a week, and if there's no single owner, the answer keeps changing. Usually this is whoever runs operations or finance, since they're the ones who will get blamed later if an invoice goes to the wrong billing contact.

Clients and Contacts: What Actually Needs to Move

Not every field in your old CRM deserves a seat in the new one. Before mapping anything, sort your client and contact records into three piles: active clients with open work, past clients you'll reference for renewals or referrals, and dead records that only exist because nobody ever deleted them. That third pile is usually 20 to 30 percent of a CRM's total row count. Leave it behind, or archive it as a flat export rather than importing it as live records.

• De-duplicate before you map fields, not after. Sort by email domain and phone number, not just company name, since "Acme Inc" and "Acme Incorporated" will look like two different clients to an import tool.
• Keep one billing contact per client, tagged clearly. If a client has three contacts and none is marked as the invoice recipient, your first invoice run in the new system will go to whoever happens to be listed first.
• Carry over the relationship notes, not just the record. Which clients pay late, which ones require a PO number on every invoice, which contact hates being CC'd. That context lives in someone's head or an old notes field, and it's expensive to relearn.
• Standardize currency and tax fields at the client level before import. If some clients were entered in USD and others in local currency inconsistently, fix it in the source data, because chasing it down after 200 clients are already loaded is much slower.

Projects, Time, and Invoice History

Client records are the easy part. Projects carry dependencies: time entries, milestones, invoices already sent, and sometimes contracts tied to a specific project ID that finance still references. Get the mapping wrong here and you end up with a project in the new system that shows zero hours logged against a client who has clearly been billed for 300 of them.

Split projects into three buckets, same idea as with clients. Active projects need full detail: every task, every time entry, every open invoice, because your team is working in them right now and needs continuity. Recently closed projects (say, closed within the last 6 to 12 months) are worth moving with reasonably full detail too, since they still come up in QBRs and renewal conversations. Anything older can usually move as a summary record: client, project name, dates, total value, final margin, without every underlying time entry. Full detail on a five-year-old closed project rarely earns its keep.

If your firm has been running on spreadsheets or a bare-bones tool up to now, this is also the point where it's worth reading through what a proper PSA actually consolidates, since the reason projects and invoices get tangled in the first place is usually that they lived in separate tools that never talked to each other. Our guide on what PSA software is and how it connects CRM, projects, time, and billing covers that in more depth if you want the full picture before you finalize your field mapping.

Cutover Day and the Two Weeks After

Pick a cutover date that isn't the same day as a big deadline for any active client. Mondays are generally better than Fridays, since it gives your team four business days to catch mapping errors before a weekend where nobody's watching. Run a parallel week if you can afford it: keep the old system read-only and available, and have two or three people spot-check specific clients and projects against it during week one in the new platform. Don't try to spot-check everything. Sample it. Pick your five largest clients by revenue, your three most complex active projects, and a handful of records at random, and verify those against the old system line by line. If those check out, the rest of the migration is very likely fine too, and you'll have caught the mapping errors that actually matter (the ones on your biggest accounts) rather than burning a week auditing records nobody looks at anyway.

The two weeks after cutover matter more than the cutover itself. This is when your team is still half-thinking in the old system's structure, and small gaps show up: a project template that didn't carry over, a rate card that reverted to a default. Keep a shared list where anyone can flag something that looks off, and review it daily for the first ten business days. After that, issues drop off fast, because by then everyone's muscle memory has shifted to the new system. If you're evaluating platforms and haven't picked one yet, it's worth comparing how different tools handle import tooling and support during onboarding on the features page, and checking what's included at each tier on pricing, since migration support varies a lot between vendors.

Frequently asked

Related reading