Contents
Move your CRM data first, then time tracking, then billing, with a dry run before every import and the old tools locked read-only for a full billing cycle. Pick a Monday for the cut-over, import everything up to the previous Friday, and bill the whole month from the new system, so no billing period ever straddles two tools.
Why does the import order matter?
Time entries point at projects, projects point at clients, and clients are the companies your CRM already knows about. Import in that order and each step matches what the last one created instead of duplicating it. Do time first and you will end up with "Acme" from the tracker and "Acme Corp" from the CRM, deals on one, hours on the other, and someone merging records by hand for a week.
| Step | Source | Entities | Depends on |
|---|---|---|---|
| 1 | CRM | Companies, contacts, deals, pipeline stages | Nothing |
| 2 | Time tracking | Clients, projects, tasks, time entries | Companies from step 1 |
| 3 | Billing | Open invoices, retainer terms, rates | Clients and projects from step 2 |
| 4 | Proposals | Templates, open proposals | Companies and contacts from step 1 |
The replacing HubSpot, Harvest and PandaDoc guide has the field mapping for those three specifically, but the order above holds no matter what you are leaving behind.
How do you dry-run an import?
A preview that tells you creates, updates and skips per entity, and names every row that would fail, is the difference between a migration and a gamble. Run it, read the problem rows, fix them at source, run it again, and only then write anything. An importer with no dry run is asking you to discover what went wrong after it has already gone wrong.
The dry run output should answer four questions before you commit:
| Question | What to look for |
|---|---|
| How many records will be created? | A number close to the count in the source; a much larger one means duplicates |
| How many will be updated? | On a first import, zero; on a re-run, the records you expected to change |
| How many will be skipped, and why? | Every skip has a reason: missing client, unmatched person, bad date |
| Which rows fail validation? | The specific row, the field, and the value that failed |
Read the skips as carefully as the failures, because a skipped time entry does not stop anything. It just disappears, and you find out three weeks later when an invoice comes up short. Anything above 1% of rows skipped is a mapping problem to fix, not a rounding error to shrug at.
Why keep the old tool read-only?
For one billing cycle, nobody writes to the old system. If something is missing you still have the source, and if the import was wrong you roll it back and go again. The old tool is your reference copy, and a reference copy people are still editing is not a reference at all.
Make read-only a setting, not a request. Downgrade the old subscription or strip everyone's edit rights the morning your team moves across, so a stray timer cannot land in the wrong place. Tell people "please don't use the old one" and someone will use it the first time the new one feels unfamiliar, and those are precisely the hours that never get invoiced.
Insist on whole-import rollback before you commit to anything. If you can undo everything one import created and nothing else, a bad mapping costs you an hour: roll back, fix it, dry run, import again. Without that, a bad import means hand-deleting records while your team is already working on top of them, and that is the scenario where you lose a month.
How do you match people by email?
Every time entry and every deal owner points at a person. If someone used a personal address in the old tracker and their work address in the new one, all their history lands on nobody. Run the dry run, read the unmatched list, add the aliases, then import. Ten minutes here saves a week of reassigning entries later.
The mismatches are always the same handful: someone who joined before you changed domains, a contractor invited on a Gmail address, a name spelled two ways, and your own original login from before there was a company account. Write them down before the dry run and the unmatched list usually comes back empty.
When should the cut-over happen?
Pick a date, not a week. Make it a Monday. Import everything up to the previous Friday, put your team on the new timer that morning, and bill the month from the new system. A migration spread across a billing period doubles the reconciliation work and all but guarantees somebody bills the same hours twice, or nobody bills them at all.
| When | What happens | Who |
|---|---|---|
| Week before, Monday | Setup wizard, users invited, rates and departments entered | Operations lead |
| Week before, Wednesday | CRM export and dry run; fix unmatched companies and people | Operations lead |
| Friday | Final export from the old tools, dry run, import CRM then time then billing | Operations lead |
| Weekend | Spot-check five clients end to end: contacts, projects, hours, open invoices | Operations lead and one account manager |
| Monday | Team on the new timer; old tools read-only | Everyone |
| Monday plus 30 days | First invoice run from the new system; old tools archived if the run reconciles | Finance |
The five-client spot check is the step everyone skips, and it is the one that catches the mapping error a dry run cannot see. Take your two biggest retainers, one hourly client, one fixed-fee project and one client with an open invoice. Open each in the new system and compare contacts, last month's hours and the invoice total against the old tool. If those five match, the rest will too.
What does a good migration cost?
A day of one person's time, plus an hour from each account manager to check their own clients. A bad one costs you a month: hours in two systems, invoices built from a merge, and a team that no longer believes any number you show them. The dry run, the read-only lock and the rollback are the whole difference.
Verbial imports from HubSpot, Pipedrive, Salesforce, Close and Zoho for CRM, from Harvest, Toggl Track, Clockify, Everhour and Productive.io for time, and from Asana and monday.com for projects, each with a dry run and whole-import rollback. To point the dry run at your own data and see what it says, start free.
Questions
How long does an agency software migration take?
With importers for the tools you are leaving, about a day: setup in the morning, CRM import, time import, a dry run for each, and your team on the new timer the next morning. Without importers, budget a week of spreadsheet work and pick your calmest month.
Should you migrate historical time entries or start fresh?
Bring across at least the current and previous billing period, so open invoices and retainer pacing carry over. Older history is worth importing if you report utilization or client profitability over time. If nobody trusted the old data anyway, a clean start from the cut-over date costs you less than you think.
What is the biggest mistake agencies make when switching tools?
Letting the migration straddle a billing period. Half a month of hours in the old tool and half in the new one guarantees you invoice something twice or not at all. Pick a Monday, cut over cleanly, and bill the whole month from one system.