How to switch interpreting platforms without downtime

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 — including the mistakes that actually cause downtime, and the questions to settle with your new vendor before anything gets exported.

Why the switch keeps getting postponed

The fear behind every stalled migration is specific, even when it goes unspoken: an interpreter fails to show because a booking lived in the wrong system, or a client gets a mangled invoice and starts wondering what else is broken. Those are real risks — of a bad migration. They are not risks of migration itself.

Every failure mode in a platform switch traces back to one of two root causes: the same job existing in two systems at once, or a billing period split across them. Design those two conditions out — with one rule for bookings and one boundary for money — and the scary version of the project simply can’t happen. Everything below is in service of those two constraints.

Week zero: export your data in dependency 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:

1. Clients first. Organizations, billing contacts, addresses, payment terms, 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, and a migration is the one time nobody will miss them.
2. 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.
3. 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. If a rate rule can’t be written down, it can’t be migrated, and it was already a liability.
4. Future bookings last. Only jobs from the cutover date forward, now that the clients, interpreters, and rates they reference are all in place. 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: run both platforms in parallel

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.

Make the rule impossible to forget: give every dispatcher a two-line placard — booking starts before the cutover date, old system; on or after, new system — and start each morning of the parallel run with a five-minute standup on one question: did anything land in the wrong place yesterday? Catching a stray same-day is trivial; discovering it the week the old system goes dark is not.

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, and walk one cooperative client through requesting a job in the client portal. Small frictions surfaced in week two are minor; the same frictions discovered the morning after the old system goes dark are not.

Cut invoicing over 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.

The first new-system billing run is also your validation gate. If your agency generates invoices from completed jobs, run that first cycle early in the month and reconcile a sample against what the old system would have produced — same jobs, same totals. A match means your rate schedules imported correctly. A mismatch tells you exactly which rule to fix, while the old system is still there to check against and before any client sees a number.

Scheduling can straddle two systems for a few weeks. Invoicing cannot.

The one rule of cutover

Week four: sunset the legacy 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 — count the instances; recurring jobs are the easiest thing to lose in a migration because next month’s occurrence may not exist yet in the export.
• Repoint every intake channel — the request form on your website, the booking email address, the phone script — at the new platform, so nothing keeps trickling into the old one.
• Tell clients and interpreters, once, where their portal now lives.
• Revoke logins, then cancel the subscription in writing and calendar the confirmation.

The playbook at a glance

Five mistakes that actually cause downtime

1. The big-bang weekend cutover. Moving every live booking in one heroic push maximizes the two failure conditions — duplicate jobs and split billing — at the exact moment nobody has a fallback. The parallel run exists so no in-flight job ever has to move.
2. Migrating historical jobs. Years of completed appointments bloat the import, multiply the ways it can fail, and buy you nothing dispatch needs. Export history to files; migrate the future.
3. Trusting recurring series to “probably” be there. A weekly series whose export only covered the next few instances will silently end mid-semester. Recreate series from the cutover forward and count the occurrences.
4. Splitting an invoice month. Any cutover date other than a month boundary guarantees at least one billing period assembled from two systems — the single most client-visible way a migration goes sideways.
5. Leaving intake pointed at the old system. If the website form or booking inbox still lands in the legacy platform, new work keeps arriving on the wrong side of your one rule, and the old system never actually winds down.

What to settle with the new vendor before week zero

A short conversation up front removes most week-two surprises. Get concrete answers to these before anything is exported:

• What import formats do you accept for clients, interpreters, rates, and bookings — and who does the field mapping, you or us?
• Can recurring series be imported as series, or do they arrive as disconnected one-off jobs?
• Can your rate engine represent our whole rate card — dual client and interpreter rates, minimums, after-hours and rush premiums, mileage, and the per-client exceptions?
• Will you help us run in parallel — training during the overlap, and a named person for cutover week?
• What does data export look like on the way out? The honest answer to this question tells you how the relationship will end, years from now, better than anything on the sales call.

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.

Frequently asked questions