The CX Platform Migration Checklist: 60 Days From Signature to First Insight

TL;DR#

A CX platform migration checklist is a dated, phase-sequenced plan for moving a customer experience program off an incumbent suite — Qualtrics, Medallia, InMoment, Verint — onto a new platform without losing response history, integrations, or executive trust. Sixty days is realistic if the work runs in this order: Days 1–10 for export and taxonomy inventory, Days 11–25 for taxonomy mapping, Days 26–40 for integration and alert rebuild, Days 41–50 for a parallel run and reconciliation, and Days 51–60 for cutover and stakeholder communications. The step that breaks timelines is almost never the data export; it is taxonomy mapping, because a decade of survey fields, driver batteries, and touchpoint codes was never documented anywhere except inside a handful of saved dashboards. Bent Flyvbjerg and Alexander Budzier's Harvard Business Review analysis of IT project risk found that roughly one in six IT projects becomes a "black swan" with a cost overrun above 200% and a schedule overrun near 70% — CX migrations fail the same way, by discovering scope in week six instead of week one. Vendor-authored migration content stops at "we'll help you migrate," which is why most CX teams have never seen a neutral timeline with explicit exit criteria per phase. This CX migration plan is deliberately vendor-agnostic: the same sequence applies whether you are working out how to migrate off Qualtrics, how to switch off Medallia, or how to consolidate three regional tools into one. The most important design decision is to define Day 60 as first insight — one real, decision-grade finding produced by the new platform — rather than "system configured."

Why CX Platform Migrations Slip#

CX platform migrations slip because the real scope lives in undocumented configuration, not in the contract or the data export. The export is a support ticket. The configuration is ten years of institutional memory: which of the 41 survey questions still feeds a live dashboard, why the driver battery has twelve attributes instead of eight, who owns the alert that pages the regional service director at 2 a.m., and which touchpoint code the finance team uses to allocate CX budget.

Three failure modes account for most of the slippage:

1. Undiscovered taxonomy. Teams budget two weeks for "field mapping" and find 600 distinct question variants across eight business units. Nobody can say which ones matter, so the mapping stalls waiting for decisions that have no owner.
2. Integration sprawl with no register. The incumbent suite is wired into CRM, the data warehouse, ticketing, Slack, SSO, and two BI tools. Each connection has a different owner, and at least one was built by a contractor who left.
3. Reporting-continuity anxiety. The program's credibility rests on a trend line in a quarterly board deck. The moment someone asks "will the number still be comparable?", the migration acquires an unfunded, unscoped analytics workstream.

None of this is unique to CX. McKinsey's joint research with the University of Oxford's BT Centre for Major Programme Management, covering more than 5,400 IT projects, reported average overruns of 45% on budget and 7% on schedule while delivering 56% less value than predicted — and found that every additional year of planned duration raised cost overruns by roughly 15%. The practical implication is counterintuitive but consistent: a tightly scoped 60-day migration is lower risk than a "careful" nine-month one, because a short clock forces the taxonomy decisions into week two instead of month five.

The other reason to compress is commercial. Enterprise CX contracts typically carry auto-renewal notice windows of 30 to 90 days, and the notice date — not the end date — is the real deadline. If you are still assessing whether to move, work the decision first with the signals that it's time to leave Qualtrics, the equivalent signs it's time to leave Medallia, and the questions CX leaders should ask before renewing Medallia. This checklist assumes that decision is made and the signature is behind you.

Days 1–10: Export, Audit, and Taxonomy Inventory#

Days 1–10 exist to convert unknowns into a written inventory: what data you have, what configuration you have, and who owns each piece. No mapping decisions happen yet. The output is a register, not a design.

Step 1: Fix the dates. Pull the order form and write down four dates — contract end, renewal notice deadline, last date of guaranteed data access, and your target cutover. Most incumbents keep data accessible for a defined post-termination window; get that in writing rather than assuming indefinite access.

Step 2: Request the full export on Day 1, not Day 30. Export requests queue. Ask for raw response-level data (not aggregates), verbatim open-text fields, respondent metadata and consent flags, sample/panel lists, survey definitions or logic files, user and permission lists, and dashboard definitions. Where the data includes personal data of EU or UK data subjects, the right to data portability under Article 20 of the GDPR entitles the data subject to receive it in a structured, commonly used, machine-readable format — and controllers generally have one month to respond. That is leverage worth knowing about, and it sets the format expectation (CSV or JSON, not a PDF report pack). The mechanics of getting a clean, complete extract are covered in detail in the guide to getting your data out of Qualtrics, and the vendor-specific sequencing lives in the 2026 playbook for migrating off Qualtrics and the guide to switching off Medallia for CX teams.

Step 3: Inventory the taxonomy, ruthlessly. For every survey, dashboard, and alert, record: name, owner, last-modified date, last-viewed date, and whether any decision in the last two quarters depended on it. The last-viewed column is the one that saves the project. In most programs, a large share of the artifact count is dormant, and dormant artifacts do not get migrated — they get archived. If you never wrote down what capability the program actually requires, borrow the structure in the customer experience platform requirements checklist and score against it.

Step 4: Inventory the humans. Name a single accountable owner, a data owner, an integration owner, and one executive sponsor. Migration decisions are cheap when the right five people are in a room and expensive when they are routed through email. If you are unsure who belongs on that list, the CX buying committee breakdown maps the roles that typically need a seat.

Exit criteria for Day 10: export requested with a confirmed delivery date; artifact register complete with owner and last-viewed columns; integration register complete with named owners; four dates written down and shared.

Days 11–25: Mapping the Old Taxonomy to a New Model#

Taxonomy mapping is the phase where you decide what not to rebuild — and it is the single highest-leverage two weeks of the whole plan. The wrong instinct is to recreate every legacy survey field one-for-one in the new platform. That reproduces the constraint you are paying to escape.

The right instinct is to map backwards from decisions. For each artifact in the register, ask: what decision did this inform, and what is the cheapest way to inform that decision in the new model? A 12-attribute driver battery that existed because a factor analysis in 2019 needed it may be replaced by a single open question with intelligent follow-up — which is a different instrument, not a degraded one. Nielsen Norman Group's catalogue of the ten biggest survey challenges is blunt about why: researchers cannot probe a survey response, so scale answers arrive with no reason attached, and the open-text box that was supposed to carry the reason is "brief, disconnected, or skipped entirely."

Use a mapping table with an explicit decision column. Four verdicts are enough:

Two rules keep this phase from sprawling. First, structured metadata ports; instruments get rebuilt. Customer IDs, touchpoint codes, region, segment, product line, language, and consent flags must survive unchanged — they are the join keys for every downstream report. Question wording, scales, and matrix batteries are candidates for redesign. Second, cap the rebuild at the artifacts that pass the decision test. Everything else is archived.

For the instruments you do rebuild, start from a known-good structure rather than a blank page: the NPS survey template and the customer journey interview template both exist to be adapted, and the twelve capabilities that separate a CXP from a survey tool is a useful cross-check that you are rebuilding into the new model's strengths rather than emulating the old one. If the mapping exposes genuinely irreducible complexity, that is a signal to revisit scope with the vendor-neutral CXP scoring framework rather than to extend the timeline.

Exit criteria for Day 25: every register row has a verdict; join keys documented; rebuild list frozen and signed off by the executive sponsor; archive list agreed.

Days 26–40: Rebuilding Integrations and Alerts#

Integration rebuild takes fifteen days because it is six parallel workstreams with different owners, not one technical task. Run them concurrently against the register you built in week one.

• Identity and CRM. Establish the customer/account join key first, before anything else is wired. Every other integration inherits it. Validate on a sample of 500 records that the key resolves in both systems.
• Data warehouse. Land response-level records in the warehouse on the same schedule as before. If CX data currently arrives nightly at 02:00, keep that contract — downstream BI jobs assume it.
• Ticketing and case creation. Rebuild the rules that turn a low score or a specific phrase into a ticket. Confirm assignment queues, SLAs, and dedupe behavior explicitly.
• Alerting. See below — this is the one most likely to be rebuilt badly.
• SSO and provisioning. SAML or OIDC plus SCIM group mapping. Do this before user training, not after; nothing erodes goodwill faster than a training session where half the room can't log in.
• BI and dashboards. Point existing reports at the new tables. Keep the old dashboards read-only rather than deleting them.

Rebuild alerts by decision, not by rule. Legacy alert sets accumulate. A typical enterprise program carries dozens of rules, many firing into channels nobody reads, which is how alert fatigue trains people to ignore the one that matters. For each alert, write one sentence: "When X happens, [role] does Y within Z hours." If you cannot complete that sentence, the alert does not get rebuilt. This is also the moment to check that the alert actually reaches a workflow rather than a dead-end channel — the failure patterns are the same ones described in what customer journey orchestration is and where it breaks.

Budget owners will ask what this phase costs in internal hours, and CX platform implementation labor is the line item most often left out of the business case. Model it honestly using the CX platform total cost of ownership breakdown, which accounts for implementation effort rather than just license fees. If the integration surface turns out to be larger than the platform can absorb, that is a build-versus-buy question, not a migration question — the build-vs-buy decision framework for a CX platform covers that fork.

Exit criteria for Day 40: join key validated on a 500-record sample; warehouse loads running on the legacy schedule; every rebuilt alert has a completed "when X, role does Y within Z" sentence; SSO live for all named users.

Days 41–50: Parallel Run and Reconciliation#

The parallel run is a ten-day window in which both platforms collect from the same touchpoints so you can quantify the difference before you depend on it. Ten days is usually enough to accumulate a reconcilable sample at typical enterprise volumes; if your monthly response count is under a few hundred, extend to twenty days rather than compressing the comparison.

Do not expect the two systems to agree. A conversational instrument and a matrix survey are different measurement devices, and the goal of reconciliation is to characterize the delta, not eliminate it. Run five tests:

Two of those deserve emphasis. A score-level gap is the expected outcome, not a defect: response populations differ when the instrument differs, and pretending otherwise is how programs end up defending a number they cannot explain. Verbatim depth is the test that proves the migration was worth doing — the practical difference between a scale-plus-comment box and a probed conversation shows up as an order-of-magnitude change in usable text, which is exactly the material analyzed in the verbatim analysis of 40,000 open-ended responses.

If you have not already run a structured trial of the new platform, this window doubles as one; how to run a CX platform pilot sets out scoring criteria that convert a parallel run into a defensible go/no-go rather than a vibe check. Keep the reconciliation output as a one-page memo — it becomes the appendix that answers every "why did the number move?" question for the next two quarters.

Exit criteria for Day 50: all five tests run and documented; deltas explained in a one-page reconciliation memo; zero unexplained alert misses; sponsor sign-off to cut over.

Days 51–60: Cutover and Stakeholder Communications#

Cutover is a sequenced ten days, and the communications work is larger than the technical work. Run it in this order.

Days 51–53: freeze and redirect. Stop new collection in the legacy platform on a named date and time. Redirect every live touchpoint — email templates, in-app triggers, QR codes, IVR handoffs, post-chat prompts, embedded widgets. Hunt for the forgotten ones: printed collateral, email signatures, partner portals, and anything embedded by a team outside CX.

Days 54–56: communicate to three audiences, differently.

• Executives get the reconciliation memo and one line on what changes in their reporting, ahead of the next review cycle — not during it.
• Frontline and operational users get hands-on training on the workflow they actually perform, plus a named person to ask. This is the audience most often skipped, and it is the one that determines adoption. McKinsey's research on organizational transformations found the success rate stuck near 30% across years of study, with engagement of line managers and frontline employees separating the programs that stick from the ones that revert.
• Customers, where the touchpoint is visibly changing, get a short, plain note. "We've replaced our feedback form with a short conversation" is sufficient; the conversation itself should explain the rest.

Days 57–58: archive and set retention. Decide, in writing, what happens to legacy data: what moves to the new platform, what goes to cold storage, what is deleted. Storage limitation and the right to erasure under Article 17 of the GDPR mean "keep everything forever, just in case" is a defensible position only where you can articulate the purpose. Then confirm deletion at the outgoing vendor: ask for written confirmation, and where the contract allows, a certificate of sanitization consistent with the Clear / Purge / Destroy categories in NIST Special Publication 800-88 on media sanitization. The retention and consent detail that belongs in this decision is unpacked in the guide to customer feedback data retention and privacy.

Days 59–60: produce the first insight. The migration is not finished when the system is configured. It is finished when the new platform answers a question that mattered: why a specific segment's renewals softened, what the top three drivers of a support-experience score actually are, what customers say when asked to describe the problem in their own words. Ship that finding to the sponsor on Day 60. It is the artifact that makes the next budget conversation easy — see the CX scorecard for the board and the seven numbers worth reporting for the framing executives respond to.

Exit criteria for Day 60: legacy collection frozen and all touchpoints redirected; three audience comms delivered; retention decision written and deletion confirmed; one decision-grade insight delivered from the new platform.

The Reporting-Continuity Problem#

Reporting continuity is the hardest part of any customer experience platform migration, and the honest answer is that you cannot make a conversational dataset perfectly comparable to a legacy survey dataset — nor should you try. Different instruments produce different response populations. Forcing agreement means degrading the new instrument until it behaves like the old one, which forfeits the reason for migrating.

What works instead is a documented method break, handled the way any serious measurement program handles one:

1. Annotate the break. Put a vertical line on the trend chart with a date and a one-line note: "Instrument changed: conversational collection from 14 March." Every analyst who inherits this chart in two years needs that line.
2. Dual-report for one quarter. Show both series side by side for a single reporting cycle, with the delta from the reconciliation memo. One quarter, not four — indefinite dual reporting is how programs end up maintaining two platforms.
3. Move the scorecard from scores to drivers. A score trend that broke is a weak asset. A ranked list of what customers say is driving the score, refreshed monthly with quotes, is a stronger one — and it survives instrument changes because it is grounded in language rather than scale calibration.
4. Retire benchmark comparisons you cannot defend. Cross-company CX benchmarks were already fragile before the migration; customer experience benchmarking without fooling yourself covers which comparisons survive scrutiny and which never did.

The reframe worth making explicitly with executives: the legacy trend line was never as solid as it looked. A score built on single-digit response rates, a static question set, and a comment box most respondents skip is a thin signal presented with false precision. This is the structural argument in what a customer experience platform is and why AI is replacing the survey suite, and the market-level version in the 2026 enterprise CXM buyer's guide to alternatives to Medallia and Qualtrics.

The Printable 60-Day CX Platform Migration Checklist#

Here is the whole plan as a single reference. Copy it into your project tracker and assign an owner to each phase.

Days 1–10

• Contract end, renewal notice, data-access, and cutover dates written down
• Full export requested with a confirmed delivery date and format
• Artifact register built with owner and last-viewed columns
• Integration register built with a named owner per connection
• Accountable owner, data owner, integration owner, and sponsor named

Days 11–25

• Every artifact assigned one verdict: port as-is, port + upgrade, replace, or archive
• Join keys (customer ID, touchpoint, segment, region, language, consent) documented
• Rebuild list frozen and signed off
• Archive list agreed with retention owner

Days 26–40

• Customer/account join key validated on a 500-record sample
• Warehouse loads running on the legacy schedule
• Ticketing rules, queues, SLAs, and dedupe confirmed
• Every rebuilt alert has a "when X happens, [role] does Y within Z hours" sentence
• SSO and provisioning live for all named users
• BI reports repointed; legacy dashboards set read-only

Days 41–50

• Both systems collecting from the same touchpoints
• Volume, coverage, score-level, verbatim-depth, and alert-fidelity tests run
• One-page reconciliation memo written
• Sponsor go/no-go recorded

Days 51–60

• Legacy collection frozen at a named date and time
• Every touchpoint redirected, including print, partner, and embedded surfaces
• Executive, frontline, and customer comms delivered
• Retention decision written; deletion confirmed in writing by the outgoing vendor
• One decision-grade insight delivered from the new platform

Frequently Asked Questions#

How long does a CX platform migration take?#

A focused CX platform migration takes about 60 days from contract signature to first insight for a single-suite program with a handful of integrations. Multi-region programs with several business units and heavy warehouse dependencies typically run 90 to 120 days. Longer timelines rarely reduce risk — McKinsey's IT project research found each additional year of planned duration increased cost overruns by roughly 15%.

Can you get your historical data out of Qualtrics or Medallia?#

Yes — response-level data, verbatims, and metadata are exportable from both, though the completeness and format vary by module and contract. Request the export on day one, specify raw response-level records rather than aggregate reports, and confirm your post-termination data-access window in writing. Where personal data of EU or UK data subjects is involved, GDPR portability rights set a machine-readable format expectation.

What is the biggest risk in a CX platform migration?#

Undocumented taxonomy is the biggest risk in a customer experience platform migration. Survey fields, driver batteries, touchpoint codes, and alert rules accumulate for years without documentation, so teams discover real scope in week six of an eight-week plan. The mitigation is a Day 1–10 artifact inventory with owner and last-viewed columns, which lets you archive dormant artifacts instead of migrating them.

Do you need to run the old and new platforms in parallel?#

Yes, a parallel run of roughly ten days is worth the overlap cost on any program that reports to executives. It gives you a documented delta on volume, segment coverage, score level, and verbatim depth before anyone depends on the new numbers. Programs collecting fewer than a few hundred responses a month should extend the window to about twenty days.

Who should own a CX platform migration?#

A single named CX program lead should own the migration, supported by a data owner, an integration owner, and one executive sponsor with budget authority. Committee ownership is the most common cause of stalled taxonomy decisions. The sponsor's specific job is to break ties on what gets rebuilt versus archived, on a fixed date.

What happens to NPS trend lines after a migration?#

NPS trend lines break at the instrument change, and the correct response is to annotate the break rather than to reconcile it away. Document the date, dual-report both series for one quarter with the measured delta, and shift the executive scorecard toward ranked drivers and customer language, which stay comparable across instrument changes in a way that a single score does not.

Next Steps: Running Your CX Platform Migration Checklist#

A CX platform migration checklist works when it is dated, owner-assigned, and ends in an insight rather than a configuration screenshot. Days 1–10 turn unknowns into registers. Days 11–25 decide what not to rebuild. Days 26–40 restore the integration and alerting surface. Days 41–50 quantify the delta between the old instrument and the new one. Days 51–60 cut over, communicate to executives, frontline users, and customers separately, settle retention, and ship one finding that matters. The reporting-continuity problem is solved by documenting the method break honestly, not by degrading the new instrument until it mimics the old one.

Perspective AI is built for the destination side of this plan: AI-led customer interviews that keep your structured metadata and join keys intact while replacing the scale-plus-comment-box instrument with a conversation that follows up, probes vague answers, and captures the reason behind the score. That is what makes a Day 60 insight possible instead of a Day 60 configuration review. Teams running this migration usually start narrow — one touchpoint, one segment, one question they have never been able to answer from survey data.

If you are at the start of the 60 days, start a research study on the touchpoint you plan to migrate first and use it as your parallel-run instrument. If you are still building the internal case, see how Perspective AI supports CX teams and read the Medallia versus Perspective AI comparison of enterprise CXM and conversational AI for the side-by-side on what changes when the instrument changes.