# The switch feels safer when the cutover has a script > Why structure choices, contact preload, transcript imports, drain-and-fill cutovers, and visible rollback plans make a support migration easier to buy. - Canonical HTML: https://growth.iangoh.com/blog/the-switch-feels-safer-when-the-cutover-has-a-script/ - Published: 2026-05-26 - Updated: 2026-05-26T03:30:00Z - Categories: support migration, switcher marketing, brand trust - Niches: SaaS, B2B software, customer support software, AI products, developer tools ## On this page - Pick the shape of the history before you promise a painless move - Identity work is boring until it is the whole migration - Readable history beats theatrical fidelity - A cautious cutover can sell better than a dramatic one - The buyer relaxes when they can see the script - Where this is most useful ## Start with these related tactics - [History structure choice before support import](/growth-ideas/history-structure-choice-before-support-import/): Decide whether imported history should become conversations or tickets before scripting the migration so the buyer sees one coherent system instead of a messy hybrid. - [Contact and attribute preload before support history import](/growth-ideas/contact-and-attribute-preload-before-support-history-import/): Create the customer contacts and required attributes before importing historical threads so every migrated record lands with the right identity and fields attached. - [Full transcript reply instead of message-by-message replay](/growth-ideas/full-transcript-reply-instead-of-message-by-message-replay/): Import the thread as one created record plus one full transcript reply when the buyer mainly needs readable history, not a perfect recreation of every old event. A lot of support migrations get sold like product upgrades. The buyer hears about AI, speed, workflows, and nicer reporting. Then the real fear shows up. Will the history survive. Will the queue get messy. Will the team spend launch week apologizing to customers. That fear usually does not go away with a better demo. It goes away when the cutover starts looking rehearsed. ## Pick the shape of the history before you promise a painless move That is why [history structure choice before support import](/growth-ideas/history-structure-choice-before-support-import/) matters. If one person thinks the imported archive will behave like live conversations and another thinks it belongs in ticket objects, the project starts with a category error. Buyers notice that kind of fuzziness quickly. They may not use the data-model language, but they can feel when the team has not decided what the new system is supposed to be. ## Identity work is boring until it is the whole migration The next move is [contact and attribute preload before support history import](/growth-ideas/contact-and-attribute-preload-before-support-history-import/). Imported threads without the right contact record attached do not feel like preserved history. They feel like debris. This is one of those operational details that quietly changes the sales story. A buyer trusts the switch more when the imported records already know who the customer is, what account they belong to, and which fields matter. ## Readable history beats theatrical fidelity I like [full transcript reply instead of message-by-message replay](/growth-ideas/full-transcript-reply-instead-of-message-by-message-replay/) because it resists a common migration mistake. Teams assume they need to recreate every old event exactly as it happened or the move will feel fake. Most of the time the real job is simpler. Preserve enough context that the next agent can read the thread and act intelligently. That is history. The rest is reenactment. ## A cautious cutover can sell better than a dramatic one That is where [drain-and-fill cutover before final support history batch](/growth-ideas/drain-and-fill-cutover-before-final-support-history-batch/) earns its keep. A buyer does not always want a heroic weekend migration story. Often they want the opposite. Move the new traffic first. Let the old queue shrink. Then clean up what is left. That approach also pairs well with [automatic forwarding and domain auth before support cutover](/growth-ideas/automatic-forwarding-and-domain-auth-before-support-cutover/) and [de-duplicate multi-inbox copies before cutover](/growth-ideas/de-duplicate-multi-inbox-copies-before-cutover/), because routing mistakes and duplicate copies are what make a calm migration feel chaotic. ## The buyer relaxes when they can see the script The strongest trust move in the batch is [cutover runbook and rollback plan before support launch](/growth-ideas/cutover-runbook-and-rollback-plan-before-support-launch/). A visible runbook changes the tone of the deal. The switch stops sounding like confidence theater and starts sounding like an operating plan. The rollback plan matters for the same reason. It tells the buyer the team is not pretending failure is impossible. It is planning for the point where something small breaks and somebody has to decide what happens next. ## Where this is most useful For customer support software, these tactics turn migration fear into something more concrete and manageable. For SaaS and AI products selling into existing workflows, they help the product look governable instead of merely exciting. For developer tools, they are a reminder that switcher trust is often won in docs, data mapping, and launch discipline long before the prettier UI gets credit. If a migration deal is slowing down, I would not ask first for a sharper promise. I would ask whether the buyer has seen the cutover script yet. ## Related GrowthDex tactics - [History structure choice before support import](/growth-ideas/history-structure-choice-before-support-import/) - Support, Product, Docs - [Contact and attribute preload before support history import](/growth-ideas/contact-and-attribute-preload-before-support-history-import/) - Support, CRM, Operations - [Full transcript reply instead of message-by-message replay](/growth-ideas/full-transcript-reply-instead-of-message-by-message-replay/) - Support, Docs, Operations - [Drain-and-fill cutover before final support history batch](/growth-ideas/drain-and-fill-cutover-before-final-support-history-batch/) - Support, Operations, Lifecycle - [Cutover runbook and rollback plan before support launch](/growth-ideas/cutover-runbook-and-rollback-plan-before-support-launch/) - Support, Operations, Internal Comms ## Essay chronology - [Newer essay: Support starts before the launch email](/blog/support-starts-before-the-launch-email/) - support-led growth, launches, brand trust - [Older essay: The launch starts looking real before launch day](/blog/the-launch-starts-looking-real-before-launch-day/) - launch strategy, brand trust, operator-led growth ## Keep reading - [The rollout usually breaks where ownership goes fuzzy](/blog/the-rollout-usually-breaks-where-ownership-goes-fuzzy/) - switcher marketing, operator-led growth, brand trust - [The switcher usually needs a place to rehearse](/blog/the-switcher-usually-needs-a-place-to-rehearse/) - switcher marketing, brand trust, operator-led growth - [The evaluation path should keep teaching after the demo](/blog/the-evaluation-path-should-keep-teaching-after-the-demo/) - switcher marketing, docs-led growth, brand trust ## Continue through the blog - [SaaS](/blog/#path-saas) - 3 essays in this path - [AI products](/blog/#path-ai-products) - 3 essays in this path - [developer tools](/blog/#path-developer-tools) - 3 essays in this path ## Sources - [Intercom Help](https://www.intercom.com/help/en/articles/9396032-historical-data-migration-to-intercom) ยท [GrowthDex source hub](/sources/intercom-help-intercom-com/) ## Editing notes - Kept the essay on one plain claim about rehearsed cutovers instead of turning migration into a grand story about transformation. - Used dull but credible details like record shape, contact preload, transcript handling, queue drain, and rollback steps so the argument stays grounded. - Cut vendor-style confidence language and let buyer anxiety about messy queues and lost history drive the piece. - Ended on a blunt sales question rather than a generic conclusion about alignment or innovation. ## Advisory If you want help turning this into a growth system, Ian Goh offers advisory at https://iangoh.com/advisory.