Nobody switches interpreting platforms because things are going well. By the time an agency starts shopping, the old system has usually been quietly taxing the team for months — workarounds in spreadsheets, invoices assembled by hand, dispatchers keeping the real schedule in their heads. And yet the switch itself gets postponed again and again, for one very rational reason: jobs are running today. There is no week on the calendar where the phones stop ringing so you can migrate in peace.
The good news is you don't need one. Agencies move platforms cleanly all the time, and the ones that do it well follow the same basic shape: a short parallel run with a hard cutover date for money. Here is that playbook, start to finish.
Week zero: export in the right order
Everything downstream depends on getting your data out in an order that respects its own dependencies. Rates reference clients and interpreters; bookings reference all three. Export in this sequence and each import lands on a foundation that already exists:
- Clients first. Organizations, billing contacts, addresses, and any account-level notes your dispatchers rely on. This is also the moment to prune — dormant accounts you haven't billed in two years don't need to make the trip.
- Interpreters second. Names, contact details, languages, certifications and their expiration dates, and standing availability. Credential expirations matter more than they look: they're what lets the new system warn you before an assignment goes out to someone whose certification lapsed.
- Rate schedules third. This is where migrations quietly go wrong. Most agencies bill clients one rate and pay interpreters another, with different minimums, different after-hours rules, and per-client exceptions negotiated years ago. Write them all down — including the exceptions that live only in your biller's memory — before you load anything.
- Future bookings last. Only jobs from the cutover date forward. Historical jobs stay in the old system for reference; dragging five years of completed appointments into a new platform adds risk and almost no value.
If you're moving to IMP, you don't have to do this alone — free data migration is included, and the team has run this export order enough times to know where each legacy format hides its landmines.
Weeks one to three: the parallel run
The rule for the parallel period is one sentence long: new bookings go in the new system; existing bookings finish in the old one.
That single rule does most of the work. Nothing gets re-keyed, so nothing gets re-keyed wrong. Every job lives in exactly one system, so there's never a question about which calendar is the source of truth for a given appointment. And the volume of work in the old platform falls off naturally as its remaining jobs complete — it winds itself down without anyone having to migrate an in-flight assignment.
Use these weeks deliberately. Dispatchers should be filling real jobs in the new platform while the safety net still exists, not clicking through a sandbox. Send a handful of real confirmations. Have two or three friendly interpreters accept assignments through the interpreter portal and tell you what confused them. Small frictions surfaced in week two are minor; the same frictions discovered the morning after the old system goes dark are not.
The cutover: money moves at the month boundary
Scheduling can straddle two systems for a few weeks. Invoicing cannot — a client receiving two partial invoices for the same month, formatted differently, from the same agency, is how you turn a smooth migration into an awkward phone call.
So pick a month boundary and hold it. Every job completed through the last day of the month is billed from the old system, as one final, complete cycle. Every job from the first of the next month onward is billed from the new one. Clients see one clean invoice per period, and your receivables report never has a seam running through it. If your agency generates invoices from completed jobs, this boundary is also your proof point: the first new-system invoice run either matches your rate expectations or tells you exactly which rate rule was imported wrong — while the old system is still there to check against.
Scheduling can straddle two systems for a few weeks. Invoicing cannot.
The one rule of cutover
Week four: sunset the old system on purpose
Legacy platforms rarely get turned off; they get abandoned, then billed for another eleven months. Close yours out deliberately:
- Confirm the final invoice cycle is issued, delivered, and reconciled.
- Export completed-job history and final financial reports to files you control.
- Verify every recurring series was recreated in the new platform — recurring jobs are the easiest thing to lose in a migration because next week's instance doesn't exist yet.
- Revoke logins, then cancel the subscription in writing and calendar the confirmation.
Four weeks, one rule for bookings, one boundary for money. The agencies that struggle with migration are almost never the ones that lacked a fancy tool — they're the ones that tried to move everything at once, or worse, ran two full systems indefinitely because no one ever named a cutover date. Name the date. The rest is just export order.