How to Switch Interpreter Management Software: A Step-by-Step Migration Guide

Changing the platform your agency runs on is one of the highest-stakes operational decisions you'll make. Do it well and you unlock years of smoother scheduling, cleaner billing, and less manual work. Do it poorly and you risk lost bookings, orphaned data, frustrated staff, and interpreters who can't see their assignments on go-live day.

This guide is a practical, vendor-neutral action plan for migrating from one interpreter management system (IMS) to another. It's written for agency owners, operations managers, and schedulers who are actively evaluating a move — whether you're leaving Interpreter Intelligence, Usked, Aqua Schedules, Fluency, or a pile of spreadsheets. It covers how to decide, what to move, how to sequence the work, and how to avoid the mistakes that derail migrations.

There's a short section at the end on how Eclipse approaches migration. Everything before it applies no matter which platform you choose.

Part 1: Decide whether you should actually switch

A migration is worth doing when the cost of staying is clearly higher than the cost of moving. Before you start, get honest about both.

Signs it's time to move:

• You're running the agency across multiple disconnected tools (scheduling in one place, billing in another, credentials in a spreadsheet).
• Routine changes — a new form field, a new user role, a workflow tweak — require a vendor request or a paid services engagement.
• Your platform's release cadence has stalled; feedback you submitted months or years ago has gone nowhere.
• Onboarding new staff takes weeks because the system is hard to learn.
• You can't get the reports you need to make decisions.
• Clients can't self-serve, so every request routes through your admins.

Reasons to pause before switching:

• You're mid-contract with an early-termination penalty. Know the number before you commit.
• Your busy season is weeks away. Migrations should land in a quieter window.
• The real problem is a process or staffing gap that new software won't fix.
• You haven't defined what "better" means. Without success criteria, you can't evaluate vendors or know when you're done.

Write down three to five specific problems you expect a new platform to solve. These become your evaluation criteria and, later, your definition of a successful launch.

Part 2: Know what you're migrating away from

Every source platform has its own quirks around data export, contracts, and what's easy or hard to extract. Confirm these details early — with your current vendor and your prospective one — so nothing surprises you at cutover.

Leaving Interpreter Intelligence

Interpreter Intelligence (interpreter.io) is a full enterprise IMS, which means you likely have a lot of configured data: interpreter profiles with certifications, client hierarchies, historical and upcoming bookings, and custom fields. Ask for a complete export of each of these and confirm the file formats. Because enterprise deployments often carry heavy customization, budget extra time to map custom fields to your new platform, and check your contract for notice-period and data-retention terms before you give notice.

Leaving Usked

Usked has deep roots in educational, community, and Deaf-services interpreting. Your data set typically includes users (interpreters, requesters), jobs/assignments, calendars, and any recurring standing orders. Confirm how Usked provides exports and in what format, and whether an API is available if you need a programmatic pull. If you run recurring educational-year schedules, plan carefully for how those recurring series map into the new system.

Leaving Aqua Schedules

Aqua Schedules is scheduling-focused, so the data you're moving is usually narrower — contacts (clients and interpreters) and your appointment calendar. That makes the extraction simpler, but note the flip side: if you're moving to an all-in-one platform, capabilities like integrated billing, credentialing, or a client portal will be net-new. Plan to configure and adopt those modules as part of the project rather than treating it as a like-for-like move.

Leaving Fluency (gofluently.com)

Fluency is an established, longer-tenured platform. Older systems sometimes lack self-serve export, so confirm early whether you can pull your own data — interpreter profiles, appointment history, and financial/invoice records — or whether you'll need the vendor's help to extract it. Get that commitment in writing, and validate a sample export before you schedule your cutover date.

Universal rule: Never give notice to your current vendor until you have a validated, complete export of your data in hand. "We'll export it later" is how agencies lose their history.

Part 3: Run a pre-migration audit

Before touching a new platform, inventory what you actually have. This audit is the single highest-leverage hour you'll spend.

Data inventory — list and locate:

• Client / customer profiles (and any parent-child account structures)
• Provider / interpreter profiles (languages, certifications, rates, service areas)
• Admin / staff users and their roles
• Past assignments / bookings (how far back do you need?)
• Future / scheduled assignments and recurring series
• Credentials and expiration dates
• Rate tables and contract terms
• Custom forms, intake fields, and templates
• Invoices, payments, and financial history

Workflow inventory — document how you actually operate:

• How a request comes in and gets assigned
• How you confirm, remind, and handle cancellations
• How visits are verified and timesheets captured
• How billing and provider pay records are generated
• Which integrations you depend on (calendar, accounting, etc.)

Stakeholders — name them:

• Project owner (single decision-maker)
• Schedulers / coordinators (daily users)
• Finance / billing
• A pilot group of interpreters and one or two friendly clients

Part 4: The migration action plan

Here is a six-phase plan you can adapt. For most small-to-midsize agencies the whole thing runs two to four weeks; larger or data-heavy migrations take longer. Durations below are typical, not guarantees.

Phase 1 — Discovery & vendor selection (a few days)

• Finalize your three-to-five success criteria from Part 1.
• Demo each finalist against your real workflows, not a generic script.
• Confirm what onboarding and implementation support is included — and what costs extra.
• Confirm data-import support: does the vendor provide import templates? Who does the mapping?
• Confirm the timeline and who owns each step.

Phase 2 — Data extraction & cleanup (2–4 days)

• Export everything from your current platform and back it up in two places.
• Clean as you go: remove duplicate contacts, inactive interpreters, and stale records.
• Standardize formats (dates, phone numbers, language names) before import.
• Decide your history cutoff — how many years of past bookings you truly need.

Phase 3 — Configuration (2–5 days, parallel with Phase 2)

• Set up your organization, locations, and service lines.
• Build your user roles and permission sets to match real responsibilities.
• Recreate your intake forms and templates.
• Configure notifications, rate tables, and billing rules.

Phase 4 — Import & validation (2–4 days)

• Map your cleaned data into the new platform's import templates.
• Import in a sensible order: profiles first (clients, providers, admins), then assignments.
• Validate: spot-check records, run a few reports, confirm counts match your source.
• Fix mapping errors and re-import affected records before moving on.

Phase 5 — Training & pilot (2–5 days)

• Train schedulers first; they're your power users and internal champions.
• Point interpreters and clients to the knowledge base and video tutorials.
• Run a pilot: process real bookings for a small group in the new system.
• For higher-risk operations, run the old and new systems in parallel for a few days.
• Collect feedback and resolve blockers before full cutover.

Phase 6 — Go-live & optimize (1 day + ongoing)

• Pick a low-volume cutover day. Communicate it to staff, interpreters, and clients in advance.
• Freeze new bookings in the old system; make the new one the source of truth.
• Keep read-only access to the old platform for a defined period for reference.
• In the first two weeks, watch fill rates, response times, and any support tickets.
• Revisit your success criteria at 30 days and tune configuration based on real usage.

Part 5: The data migration checklist

Use this as your master list. For each item, confirm you can export it from the old system and import it into the new one.

Data type	Export from old?	Import template ready?	Validated?
Client / customer profiles	☐	☐	☐
Provider / interpreter profiles	☐	☐	☐
Admin / staff accounts & roles	☐	☐	☐
Past assignments / bookings	☐	☐	☐
Future / recurring assignments	☐	☐	☐
Credentials & expirations	☐	☐	☐
Rate tables	☐	☐	☐
Forms & templates	☐	☐	☐
Invoices / financial history	☐	☐	☐

Part 6: Realistic timelines

Most agencies over-estimate the software learning and under-estimate the data cleanup. A realistic view:

• Two weeks is achievable for a small agency with clean data, few integrations, and a dedicated project owner.
• Three to four weeks is typical when you're migrating several years of history, rebuilding forms, and training a larger team.
• Longer applies to enterprise deployments with heavy customization, complex approval chains, or many integrations.

The biggest timeline drivers are the amount of data you migrate, how clean it is, and how much dedicated time your team gives the project — not the complexity of the new software.

Part 7: Common pitfalls (and how to avoid them)

• Giving notice too early. Validate your export first. Always.
• Migrating dirty data. Duplicates and dead records follow you into the new system. Clean first.
• Skipping the pilot. A short pilot surfaces the issues a demo never will.
• Training everyone at once on go-live day. Train schedulers early; stage the rest.
• No single owner. Migrations stall when responsibility is diffuse. Name one person.
• Forgetting the humans. Interpreters and clients need advance notice and a place to get help. Communicate early and often.
• No definition of done. Without success criteria, the project never truly ends. Set them up front.

Part 8: Questions to ask any vendor

• Is onboarding and implementation support included, or an added cost?
• Do you provide import templates for profiles and assignments? Who does the mapping?
• Can I customize forms, templates, and permissions myself, or does that require your team?
• How often do you ship updates, and how is customer feedback prioritized?
• What does a typical migration timeline look like for an agency my size?
• What happens to my data if I ever leave?

How Eclipse approaches migration

Eclipse was built by professional interpreters and agency owners, so its migration process is designed around the plan above. Free onboarding and implementation support is included with every subscription (scaled to your tier), so you're not paying extra to get live. Free historical data migration — your most recent 12 months of booking history, plus all client, provider, and admin profiles, are imported free as part of onboarding. Booking records older than 12 months (measured from your go-live date) can be migrated at a one-time rate of $0.10 per booking record. Import templates cover client, provider, and admin profiles plus past and future assignments, so your history comes with you. Customizable forms, templates, and permission sets are self-serve from day one — no dev fees. And because the platform is intuitive, most teams learn it in a single day, which is why the average Eclipse agency launches in two to four weeks.

Whatever platform you choose, work the plan: decide deliberately, audit thoroughly, validate your data, pilot before you cut over, and communicate with the people who depend on your schedule. That's what separates a smooth migration from a painful one.

Want a migration plan mapped to your agency's data and timeline? Schedule a walkthrough and we'll build it with you.