# The switch should feel boring before it feels done > Why the best migration story is usually quiet: simpler history, sample runs, staged cutovers, guarded workflows, and visible office hours. - Canonical HTML: https://growth.iangoh.com/blog/the-switch-should-feel-boring-before-it-feels-done/ - Published: 2026-05-25 - Updated: 2026-05-25 - Categories: switcher intent, migration, trust - Niches: SaaS, developer tools, customer support software, AI products ## On this page - Most buyers do not need a perfect copy of the past - A safe sample beats a big promise - Cutovers get easier when you split stable history from live work - Bad automation can make a good migration look broken - People still need to know who is carrying the move - Where this is most useful ## Start with these related tactics - [Simplest-form history import for reporting continuity](/growth-ideas/simplest-form-history-import-for-reporting-continuity/): Migrate historical support data in the lightest useful format so buyers keep reporting continuity without turning the switch into a transcript reconstruction project. - [Batch test migration on sample records first](/growth-ideas/batch-test-migration-on-sample-records-first/): Run the first real migration on a small sample set in a test workspace so the switch learns on safe data before touching the live queue. - [Delta-date cutover for support migration](/growth-ideas/delta-date-cutover-for-support-migration/): Choose a fixed delta date, move closed history first, then bring over the remaining open and pending work at formal cutover. A lot of software switches are sold as exciting moments. The teams living through them usually want the opposite. They want the move to feel ordinary. They want the old numbers to still make sense, the open work to still be there, the customers not to get strange emails, and somebody credible to answer the awkward questions. If the migration feels dramatic, trust is already leaking. ## Most buyers do not need a perfect copy of the past That is why I keep coming back to [simplest-form history import for reporting continuity](/growth-ideas/simplest-form-history-import-for-reporting-continuity/). Intercom makes the point plainly. If the real goal is reporting continuity, then a lighter migration is often better than rebuilding every old message. This matters for growth because the switcher is not buying historical theater. They are buying confidence that the new tool will not erase context. ## A safe sample beats a big promise The next useful move is [batch test migration on sample records first](/growth-ideas/batch-test-migration-on-sample-records-first/). A sample run in a test workspace gives the buyer something better than reassurance. It gives them evidence. Once a support lead can inspect a handful of migrated records, the conversation changes. You are no longer arguing about whether the migration will work in theory. You are checking what still needs to be fixed. ## Cutovers get easier when you split stable history from live work I like [delta-date cutover for support migration](/growth-ideas/delta-date-cutover-for-support-migration/) for the same reason. It gives the team a sequence they can reason about. Move the closed history first. Move the active queue when the moment is right. That is a better growth surface than it sounds. A buyer with a believable cutover path is far more likely to move forward than a buyer staring at one giant migration day. ## Bad automation can make a good migration look broken The least glamorous tactic in the batch may be the most important: [workflow exceptions before API-led migration](/growth-ideas/workflow-exceptions-before-api-led-migration/). Imported records can trigger surveys, emails, and workflow side effects that look absurd to customers and chaotic to the team. That kind of failure is especially expensive because it attacks trust right when the new vendor is trying to earn it. ## People still need to know who is carrying the move The final piece is [migration task force with office hours](/growth-ideas/migration-task-force-with-office-hours/). Automattic's move to Linear worked in part because the migration had named owners and recurring help. That sounds obvious. It is still rare. The practical lesson is simple. A switch does not feel safe because the new tool says migration is easy. It feels safe because the buyer can see the people, checkpoints, and fallback logic before anything important moves. ## Where this is most useful For SaaS, this usually matters when you are trying to win a team off an incumbent with years of messy history. For developer tools, it matters when the evaluation gets blocked by workflow risk instead of missing features. For customer support software, it matters almost immediately because reporting, conversations, and automations are all tied to customer trust. For AI products replacing older systems, it matters because the buyer often believes the model may be smart but the migration may still be reckless. If a category feels crowded, one of the cleanest ways to stand out is to make the switch look calmer than the incumbent makes the stay. ## Related GrowthDex tactics - [Simplest-form history import for reporting continuity](/growth-ideas/simplest-form-history-import-for-reporting-continuity/) - Docs, Sales, Support - [Batch test migration on sample records first](/growth-ideas/batch-test-migration-on-sample-records-first/) - Docs, Product, Support - [Delta-date cutover for support migration](/growth-ideas/delta-date-cutover-for-support-migration/) - Docs, Support, Operations - [Workflow exceptions before API-led migration](/growth-ideas/workflow-exceptions-before-api-led-migration/) - Lifecycle, Support, Product - [Migration task force with office hours](/growth-ideas/migration-task-force-with-office-hours/) - Community, Lifecycle, Sales ## Essay chronology - [Newer essay: The support switch usually leaks in the routing layer](/blog/the-support-switch-usually-leaks-in-the-routing-layer/) - support-led growth, migration, seo - [Older essay: The switch usually needs a map before a pitch](/blog/the-switch-usually-needs-a-map-before-a-pitch/) - switcher intent, product marketing, SEO ## Keep reading - [The switch should look like current work before the cutover](/blog/the-switch-should-look-like-current-work-before-the-cutover/) - migration, project operations, developer tools - [The alternative page should make the switch feel testable](/blog/the-alternative-page-should-make-the-switch-feel-testable/) - seo, switcher intent, brand trust - [Feedback only helps when the customer stays attached](/blog/feedback-only-helps-when-the-customer-stays-attached/) - support-led growth, product strategy, switcher intent ## 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/) - [Linear](https://linear.app/customers/automattic) · [GrowthDex source hub](/sources/linear-linear-app/) ## Editing notes - Cut the article around one plain claim about migration trust instead of inflating it into a transformation story. - Kept paragraphs short and concrete, with specific operational details replacing generic talk about change management. - Used first-person judgment sparingly to make the piece feel like operator advice rather than neutral content marketing. - Ended on a practical buying lens instead of a generic summary about customer success. ## Advisory If you want help turning this into a growth system, Ian Goh offers advisory at https://iangoh.com/advisory.