The Two Migration Models: Why Both Leave Revenue on the Table

The Moment Every Growing SaaS Platform Hits

At a certain growth stage, migration stops being a customer success concern and starts being a growth constraint. You're winning competitive deals. Customers are choosing to leave established platforms and move to yours. The sales motion is working. And then, consistently, something goes wrong during onboarding.

Customers who most needed to arrive fully operational land with gaps. Workflows they depended on weren't reconstructed. Configurations that took months to build need to be rebuilt from scratch. The team that was supposed to be productive from week one is spending its first month recreating what it already had.

When this pattern becomes visible, most teams reach for one of two solutions. Some hire a migration specialist. Others build or deploy a self-serve migration tool. Both decisions are reasonable. Both produce results.

Both also hit a ceiling. And the ceiling matters, because what sits above it is revenue.

That ceiling isn't theoretical. Jason Lemkin, founder of SaaStr, put a number on it after it stopped one of his own deals:

"I was trying to give this vendor $80,000 a year. And a $7,500 migration fee stopped me cold."

The cost of the migration wasn't the issue. The friction was. A motivated, budget-approved buyer walked away from an $80,000/year contract because the switching cost was surfaced too late and felt too high. The vendor lost $240,000 in three-year contract value over a $7,500 line item. Lemkin documented this in November 2025 on SaaStr.

Migration isn't just a retention problem. It's a sales problem. Deals stall or die because prospects know what switching will cost them before they've even signed.

This article maps out both models, where each one breaks down, and what changes when you combine the strengths of both. For the full picture of why migration quality matters this much in the first place, The SaaS Onboarding Gap covers what customers switching platforms actually expect. The Migration Bottleneck explains why the manual approach to closing that gap doesn't scale. This article is about the structural choice you face after you've accepted both premises.

Model 1: The Migration Specialist

The specialist model is how companies provide 100% migration quality. One person, or a small team, who knows your platform and the source platforms your customers are leaving. They collect credentials. They log in. They go through the source platform systematically and move everything over.

This model works because a human being with access to the source platform can see everything the platform shows. Not just what the API exposes. Everything. Every template. Every automation, including the conditional logic that doesn't serialize cleanly into a data export. Every configuration setting buried three levels into the account preferences. The specialist misses things when they run out of time, not because the data is inaccessible.

Companies that have built this model often reserve it for their highest-value accounts. A customer above a certain spending threshold gets a dedicated specialist assigned. Someone collects credentials, works through the source platform, and handles the full reconstruction. The customer arrives operational. Churn during onboarding for these accounts is low, because the experience is genuinely complete.

Nathan Barry, founder of Kit (formerly ConvertKit), ran this model in its rawest form during his company's early growth. Pitching potential customers, he kept hearing the same objection: "oh I'd love to switch, but switching an email provider is so much work." His response, described in a Groove interview: "it's not that much work, and to prove it to you, I'll do the migration for you for free." He then spent his days exporting subscribers from competitors and swapping signup forms on customers' sites, for accounts of any size. His conclusion: "if I took that objection away by offering to do the switch for them for free, that took away nearly all of their reasons for not doing business with us." ConvertKit grew from $1,300 to $5,000 in monthly recurring revenue in six months. The specialist doing migration was the product.

The ceiling is economics. One specialist can handle a limited number of migrations per quarter at full quality. A thorough migration for a complex customer can take 20 to 40 hours of work. That puts a hard ceiling on how many migrations one person can cover, and it creates a floor on the deal size at which specialist support becomes economical.

You can hire more specialists, but each hire is a cost center, not a scalable system. There's also a threshold problem. If each migration costs that much in specialist time, you can only offer it above a certain contract value. Customers who fall below the threshold get a different experience: documentation, a setup checklist, and self-serve tooling. Which means your most expensive-to-win customers get your best onboarding, and your mid-market customers get your weakest.

And even the customers who do qualify for specialist treatment are your highest churn risk if the migration falls short of their expectations. The stakes around this are detailed in Why Your Best Customers Are Your Highest Churn Risk.

Model 2: The Self-Serve Migration Tool

The tool model is how companies scale migration coverage without scaling headcount. Customers run the tool themselves, or a lightweight internal process manages the queue. Migrations happen without specialist involvement. Volume increases without proportional cost.

The scale economics are real. A tool that handles 200 migrations per quarter without 200 hours of specialist time is genuinely valuable. For straightforward migrations, this works well. Core records transfer. Contacts import cleanly. Standard fields map correctly.

The ceiling is completeness. Based on what migration teams report, self-serve migration tooling typically covers 30 to 55 percent of a customer's full setup. The gaps concentrate in the same places every time: automation and workflow logic, templates and structured assets, account configurations, platform-specific settings. These aren't edge cases. They're the parts of the migration that customers depend on most.

A migration that covers contacts and basic fields but misses automations and templates isn't 60% of a migration. For a customer whose daily operations run on those automations, it's closer to 10% of what they actually needed.

The support burden that follows is predictable. Customers who run a self-serve migration and discover gaps don't typically self-solve. They open tickets. The specialist time you saved on the migration reappears in post-migration support, distributed across more tickets, harder to triage, and landing at a point in the customer relationship when goodwill is already strained.

For low-complexity customers, the tool works well. For the high-complexity customers described in Why Your Best Customers Are Your Highest Churn Risk, the completeness ceiling is a churn risk, not an acceptable tradeoff. These customers have the most to lose from an incomplete migration, the highest expectations about what "done" looks like, and the least patience for spending weeks reconstructing what they already had.

The Gap Both Models Leave

The specialist model protects high-value customers above the threshold. The tool model covers low-complexity customers below a complexity ceiling. The gap between them is not a niche segment. It is where most competitive wins actually land.

Consider where most migrations sit in practice. A customer switching from an established platform with a year or two of history isn't simple. They have 10 to 20 automations, a set of templates they use regularly, and account configurations that affect how the platform behaves. They're not complex enough to qualify for your highest-touch specialist process, but they're too complex for self-serve to cover completely.

The mid-market segment falls into the gap from both sides. The specialist threshold is above them, so they get self-serve. But their complexity exceeds what self-serve handles well, so they arrive incomplete. Three weeks after migration they're still finding things that don't work the way they expected.

This is where the pricing threshold problem compounds what's described in The Migration Bottleneck. If specialist support only kicks in above a certain ACV, your sales team is closing deals knowing the onboarding experience they're selling into is incomplete for a meaningful portion of the pipeline. The gap isn't a failure of effort. It's a structural consequence of two models, each optimized for one end of the customer distribution, with the middle underserved.

But the specialist model proves something important: 100% completeness is achievable. The 30 to 55 percent ceiling on self-serve tooling isn't an inherent limit of migration as a category. It's a limit of what programmatic extraction can reach without a human in the loop. The question is: how much of the systematic extraction work can automation handle, so the specialist's time is freed for the parts that actually require their expertise?

The specialist model sets the ceiling. Automation changes the economics of how many customers you can serve at that ceiling.

How Automation Changes the Economics

A specialist doing a migration manually spends most of their time on systematic extraction. Moving contact records. Pulling templates out of the source platform one by one. Reconstructing automation logic by reading through flow diagrams and rebuilding them in the destination. These steps are not judgment-intensive. They're thorough and necessary, but they don't require the specialist's expertise. They require time and access.

Automation handles this layer. The extraction work that takes a specialist 20 to 30 hours of systematic effort can run in the background while the specialist does something else. What remains for them is the work that actually requires their skills: reviewing the output, handling exceptions, translating logic that doesn't map cleanly between platforms, and managing the customer through the transition.

The effect on economics is direct:

• Threshold drops. If each migration consumes 4 specialist hours instead of 30, you can offer migration support at a much lower deal size. The economics of high-quality onboarding extend further down your customer distribution. Deals that previously went without specialist support can now get it.
• Capacity scales. Same specialist, many more migrations per quarter. Not because they're working faster, but because the repeatable work isn't theirs anymore. One specialist can oversee a volume that would have required three or four before.
• Quality rises on the systematic parts. Automation doesn't get tired. It doesn't skip the 47th template because the 46 before it were tedious. Systematic extraction is more complete when it runs exhaustively rather than until someone runs out of time.
• The self-serve gap closes. For customers who don't get specialist support, automation handles what APIs don't expose. Completeness goes from 30 to 55 percent to something meaningfully higher, because the extraction layer reaches below the API surface.

This aligns with what Lemkin has argued consistently. Asked in a SaaStr Q&A about whether it's worth investing in migration support when competing against an incumbent, he put it simply: "Even if it costs you $20K or more per deal, it's worth it." The logic holds because retention follows completeness: a customer who arrives fully operational stays. A customer who arrives with gaps is already second-guessing the decision.

Teams that use this model describe a shift in how they think about migration capacity. Instead of triaging which customers get specialist attention, they can provide a consistent foundation across all customers, with specialist time applied to the parts that actually need it. The specialist becomes a reviewer and exception handler rather than a data mover.

That is not a downgrade for the specialist. It's a better use of their skills. And for the customer, it means a more complete migration with more attentive support, because the specialist has the capacity to actually pay attention to them rather than racing through a checklist.

Three Scenarios

Where you start determines what combining automation with specialist judgment looks like in practice.

You have a migration specialist and want to scale

This is the most direct application. Your specialist already knows how to do migrations well. Automation extends how many they can cover and improves what they can cover at each tier. You don't change what a migration looks like for the customer. You change how much of it your specialist has to do manually.

In practice, this means your specialist shifts from doing migrations to overseeing them. They review the automated output, handle exceptions, and spend their time on the judgment calls that require their expertise. Your migration capacity grows without a proportional headcount increase.

You can also drop your threshold. If specialist-assisted migration now costs a fraction of what it used to in staff time, the deal size at which it becomes economical to offer it goes down. More competitive deals come with migration support that can actually deliver. Churn during onboarding drops across a broader tier of customers, not just your highest ACV accounts.

You have a self-serve tool and want to close the completeness gap

Your tool handles what APIs expose. Automation handles what they don't. The completeness ceiling lifts for customers at every complexity level.

The most visible effect is in support volume. Customers who used to discover gaps two or three weeks after migration start arriving more complete. Tickets about missing automations and templates decline. Your support team spends less time on post-migration reconstruction and more time on questions that are genuinely about your platform rather than about what didn't transfer from the last one.

There's also an effect on which customers you can retain. The customers who currently fall outside your self-serve tool's coverage, the ones with complex setups who self-serve and then churn, become reachable with higher completeness. You don't have to hire specialists to support them. The extraction layer does more of the heavy lifting.

You have neither and want to build the capability

This is the scenario where building internally starts to look attractive, and where Why Your Internal Migration Build Stalls at the Source is worth reading first.

The short version: your engineering team can handle the write side of migration. Extracting data from competitor platforms, each with its own API shape, authentication scheme, and data model, is where internal builds consistently underdeliver. Without a solid extraction layer, the migration capability you build doesn't close the gap you're trying to close.

A migration capability that matches what a specialist can deliver is not a one-quarter engineering project. Teams that start there usually discover this partway through and reassess. The ones who figure it out faster are the ones who recognize the source platform problem early and scope accordingly: own the destination, embed the extraction.

The common thread across all three: the extraction layer is the constraint. It's what limits how many customers the specialist can cover, what percentage the tool achieves, and what the internal build can reach. The destination side, writing migration data into your platform, is a manageable internal project. The source side is where every migration model hits its ceiling.