#The challenge
Two customer-success platforms, two health-score models, and one shared CRM underneath. The platforms are not structurally analogous: one organises around organisations, users and products; the other anchors on accounts, contacts, subscriptions and custom objects. Roughly 130 automations already running in the primary platform would start firing at the incoming accounts the moment they landed. The primary platform was already at its ceiling for tracked product events. And the incoming health score was six weighted factors including a manual sentiment input, against a primary-platform model that needed to work across three product tiers.
#The approach
Decide what not to migrate before mapping anything
All two dozen automations and all ten structured plans in the source platform were triaged into migrate, do not migrate, source-platform-specific process, and pending-a-decision. Five automations were retired outright — at-risk alerting, two segment-driven flows, a time-boxed campaign, and unsubscribe handling — because they either duplicated something the primary platform already did better or had already expired. Six of the ten plans did not move. A migration is the cheapest opportunity you will ever get to delete things, and the triage sheet is the artefact that makes deletion a decision rather than an accident.
Write the parity map object-by-object, including the gaps
Structured plans map to journeys; plan tasks to journey steps; rules to plays; automation bundles split across plays and journeys depending on whether they are outreach or a structured plan; lifecycle properties become a combination of stages, segments and journeys because there is no single equivalent; dynamic lists and custom properties map one to one; surveys move to the native survey module. The genuinely useful column is the one recording what has no equivalent — there is no account-created-date field on the target platform, which blocked the new-account welcome play outright, and the lifecycle field the source platform maintained through an automation had no counterpart and had to be created.
Solve the co-existence problem with two fields, not three
The design question was how to stop roughly 130 live automations in the primary platform from enrolling the incoming accounts. The first proposal was three fields: a business-unit picklist, a legacy flag, and a boolean exclusion switch. It got argued down to two — business unit, and a legacy-customer boolean — because the third was doing work the first two already did. Every existing segment in the platform, roughly six hundred of them, then had to be updated to carry the filter. That is the unglamorous cost of co-existence, and it is almost always larger than the migration itself.
Rebuild the health score rather than porting it
The source model weighted six elements differently across three scorecards — a default profile leaning on product usage and user engagement at 40% each, a new-customer profile leaning on survey score at 50%, and a top-tier profile that introduced advanced product usage. The replacement is four factors: license utilisation at 30%, and meetings, feature adoption and engagement at 20% each, with a manual churn-sentiment input that can override. Utilisation is computed separately for administrator and standard seats because they behave differently. Engagement is scored on whether a contact in a decision-making persona has been seen recently, not on volume of activity. Three variants exist because the product tiers expose different functionality — scoring a customer on features their tier does not include is how health scores lose credibility.
Score on bands with an inverted scale so red is unambiguous
Each factor converts to points where more points mean worse health, with explicit thresholds rather than a continuous curve: full seat utilisation scores zero, half scores five, a quarter scores fifteen. Meetings held against meetings planned for the year band the same way. Feature adoption and engagement are binary tests over a recency window. Manual sentiment carries a large point value at the top end so a customer-success manager's judgement can force the score red without arguing with the arithmetic. That override is the part teams most often leave out and most often need.
Derive the persona field in the CRM, not in the success platform
The engagement factor depends on knowing whether a contact is a decision-maker. That was built as a title-mapping formula in the CRM covering roughly seventy title variants across four personas — executive, board or director, legal and governance, and executive administrative — and then synced across. Deriving it upstream means every downstream system gets the same answer, and the mapping can be extended in one place as new titles appear.
Set sync direction per field, with the CRM as source of truth for commercials
Around 110 account fields and 40 contact fields were mapped with an explicit direction on each. Financial and firmographic fields — recurring revenue, package, renewal date, ownership — flow one way from the CRM. Fields the success team authors — health sentiment, renewal risk and its notes, growth notes, account classification, target time-to-value — sync both ways. Getting this wrong in either direction is how a CRM ends up with a success platform overwriting its renewal dates.
Name the platform ceilings that shape the design
The primary platform caps tracked product events, and the team had already hit that cap, against several hundred distinct event types emitted by the product. That constraint is why feature adoption is scored on a small selected set of events per tier rather than on everything. Separately, meetings had been logged into the source platform by hand; manual event creation is possible on the target platform but does not scale, so the recommendation was to feed them from the conversation-intelligence tool's existing integration instead.
Stage the cutover with a freeze, a small validation sample, and a read-only wind-down
The methodology is a migration weekend with a 48-hour change freeze on the source platform, a final extract and load, then spot-checking ten to twenty accounts across tiers to confirm recurring revenue, renewal dates, ownership and recalculated health. Load order is accounts and contacts first, then subscriptions, then activities and notes. The source platform stays read-only for a month or two with integrations switched off before the licence is cancelled. In practice the team also picked two representative frequent-flyer accounts to move first and test against before running the rest.
Sequence the integration decisions rather than deferring them
Each connected system needed its own call: the analytics tool that had been the survey source needed an export-and-import plan and an open question about whether the target platform had an equivalent; the support tool needed a retain-or-retire decision within a defined window, and if retained, a CRM connection for case data; the product-usage data being ingested through the source platform's analytics API needed a new path into the target. Leaving these open is what turns a platform migration into a six-month tail.
#Outcomes
Structured plans and segments migrated and confirmed complete
All four in-scope structured plans were rebuilt as journeys on the target platform and confirmed loaded. Every segment associated with a play was updated and completed, which is what makes the business-unit filter actually hold.
About half the in-scope automations were built, with the blockers named
Cancellation, survey-reset, survey, upsell and support-ticket plays were built and are tracked with live links. Several more were built but flagged as needing attention for a specific, stated reason — one needs a billing contact to exist on the account to send at all; another is blocked because the target platform has no account-created-date equivalent. The remainder are dependent on user-role data landing first.
A new health-score framework designed and approved
The four-factor model with tier variants was approved by the customer, and this business unit was designated the first adopter of the framework before it rolls wider. The recency windows and the per-tier feature-event lists were still marked to be defined at the point the record ends, so the model is approved but not fully specified.
No cutover date was ever set in the record
The plan carries a target migration date field that stayed unset throughout, and the last dated entry is a meeting agenda, not a completion. User acceptance testing was scoped with a dummy account and a defined test script. Treat this card as a design-and-build account, not a completed migration.