I’ve sat through planning for scores of major B2B migrations, and implemented a half-dozen of my own. Usually the discussion is highly technical: APIs, data transformation, feature ladders. But most of the migration failures I see are driven by organizations’ unwillingness or inability to stick with the very hard choices that B2B/enterprise migrations demand. We lack backbone, resolution, clarity.
Let’s walk through this with a (slightly) hypothetical example. Imagine that we’re an MRP software company with thousands of manufacturing and logistics customers, mostly running our older on-premise application. We’ve built and recently launched a multitenant SaaS version as well. It’s obvious that on-premise is a dying segment (two years away from obsolescent since the 90’s), so we’re planning to migrate our customers to the Cloud.
Goals
What are we trying to accomplish? Why is this important?
- We have development teams maintaining lot of (mostly old) product versions including 10+ on-prem threads. And most of our older on-prem accounts have customized their installations with unique data integrations, facility-specific workflows, and third-party dashboards. Supporting decades of back revs consumes more engineering effort than building the future.
- Newer competitors with a single MRP product version running in the Cloud are out-maneuvering us (less history to maintain) and underpricing us (each incremental customer costs very little). Our market share is at risk; most new deals are cloud-only.
- Our on-prem customers have conflicting demands of us: an ongoing stream of fixes and improvements that don't require upgrading their fragile factory systems or re-implementing any custom integrations.
- Multitenant SaaS sales are much faster to deploy than on-premise deals, partly because vendors dramatically limit opportunities for endless low-value customization. We want “signed and running in 90 days” stories instead of our traditional “years and $Ms and high risk and agonizing upgrades.”
- The need for professional services is a burden — even though we get paid for it. Our PS team is overcommitted and under-resourced. We can’t deliver as fast as Sales can close. Revenue recognition issues, quality issues, little documentation, and no ongoing support as we move PS staff to the next urgent engagement. (BTW our investors hate it.)
Our on-premise installed base might look like this:
Note that our thousands of on-prem customers are scattered across many product versions, none of which have ever been completely retired or replaced. V11 launched in 2015, and still has an active population. V11.5 arrived in 2016, v12 in 2017… in the absence of a strong forcing function, these old versions will persist forever.
There’s some magical thinking that pops up in migration discussions: that we’ll be able to quickly build a 100%-plug-compatible cloud version of our app suite that makes migrations into the cloud completely painless; and that this is mostly a technical problem for Engineering and our field success managers to handle. Instead, the biggest challenge I see is the executive team’s willingness to approve and stick with non-negotiable end dates in the face of disgruntled customers and short-term revenue goals.
A Few Ugly Truths
The following have been true for every major B2B migration that I’ve seen:
- Our cloud implementation will never be 100% compatible with any of the various on-premise versions we’ve shipped over the years. Hard-won lessons from replatforming apply, including the need to drop old or deprecated features; lack of complete specs; major differences between cloud and on-prem infrastructure; old business logic entwined with platforms; undocumented features; modern expectations about UX and workflows; and an endless assortment of quick-and-dirty custom extensions.
- Moving MRP to the cloud is on most of our installed base’s 5-year strategic plans, as it has been for the last decade, but rarely makes it into their 1-year plans. They’re waiting for a no-cost, instant, painless, risk-free migration that doesn’t require any changes to their current workflows or other software or security model. (Unlikely, see #1 above.) So while most new customers start in the cloud, most existing on-prem customers have to be pushed every step of the way no matter what their leadership tells us in CAB meetings.
- Every new enterprise customer expects 3-5 years of support for whatever they license. So if we close one new on-premise deal today, we’ve extended the support period for that release 3+ years from today – to at least February 2026. And one on-prem deal next month resets that to March 2026, etc.
- Engineering has to be staffed, trained and ready to fix serious problems for any customer using any supported version of our products. So we don’t free up significant development resources until the very last customer deletes the very last production copy of a release. That long support tail costs us $Ms/year.
Ugh! So how do we approach this?
Identify Migration Cohorts, Not Individual Accounts
Early on, many of our installed customers will (each) need something (different) that’s not yet available in our cloud implementation. “BigCorp’s workflow uses e-signatures, which aren’t supported yet” and “MegaBank’s identity platform is SecureAuth” and “GovAgencyX is still on Internet Explorer v9.” If we chase one big non-conforming account at a time, we’ll constantly reshuffle roadmaps and make little progress.
Instead, we should identify a group (cohort) of installed customers who could migrate right now – based on whatever is already implemented in our cloud. For example, we might see that 9% of customers only integrate with NetSuite (which we have), use Okta identity management (which we support), and don’t need <10ms response time. They become Cohort 1.
We could migrate another 7% when we add just one more feature – perhaps an AWS auditing API or multilingual support. They become Cohort 2. And so forth.
This peels off large groups of migratable customers for us to engage, setting aside feature/function blockers so we can focus on commitments, benefits, incentives, technical support, and customer-side politics.
The best ongoing success metric is “percent of total customers running in the cloud.” That includes new customers (should be 100% cloud) and successfully migrated installed base users. Over time, we’re left with fewer and fewer laggards with increasingly unique challenges.
Set Hard, Non-Negotiable, No-Exception, CEO-Supported End-of-Support Dates
As we work through the cohort process, we’ll surely have some customers who can’t (or won’t) migrate. And these will likely include a few of our biggest accounts or earliest users... who have the email addresses of our VP Sales and CEO... who will make persuasive arguments about why they need more time or special handling or simply refuse to move… who will wait until days before any mandated migration dates to demand more time.
Note that this is an organizational (i.e. political) issue, not a technical issue. If MassiveCorp’s escalation to our CEO leads to an exception – an extra few quarters for them to hire consultants or review security processes or redesign workflows, all after 3 years of relentless end-of-support notifications and pleas and planning meetings – then this undermines the entire migration effort. The rest of our sales team will immediately hear about it, and elevate dozens of other customer escalations to the CEO. Our migration will stall at 75%-85%, and we’ll accrue none of our intended economic or engineering gains. (Murphy’s Law: there will be 1-2 holdout customers on every release we’ve ever made.)
So a serious question for the full executive staff before we embark on this journey: are we willing to set a hard, non-negotiable date for formal end-of-support of our on-premise products? No specials, no big-account exceptions, no excuses, no backtracking, no waffling, no “they didn’t get the memo.” Framed as a C-suite thought experiment: “if HugeCo phones the CEO three weeks before our hard migration deadline and demands another year’s support for v14 on-premise, what will we say?”
At some companies, our history and culture suggest that we’ll make just this one exception for just this one top-20 account. And the next, and the next. If so, we should rethink our objectives now. Past behaviors suggest we’ll be supporting our long tail anyway – for another decade or two.
Likewise, we have to choose a hard date to stop selling any new on-premise licenses. “On what date are we willing to turn down all new requests for on-prem, which includes terminating all commissions on new on-prem deals, without exception?” Otherwise we have a leaky bucket problem: even one new on-prem deal this quarter pushes the real end-of-support date back at least 3 years. In a sales-led enterprise software company, this is a very difficult negotiation… worth having before we commit a migration to the Board. If our exec team won’t (can’t) realistically make a hard cutoff stick, then let’s keep on-prem on our price list.
A ladder of non-negotiable hard dates might look like:
- October 2024: all new deals must be for our cloud product. No exceptions, no commissions for on-prem, no old proposals honored. Staunch the bleeding.
- June 2025: Hard end-of-support date for current customers on v11, which is already obsolete. Free upgrade to latest cloud-only version, various support and technical assistance available.
- October 2025: Hard end-of-support date for current customers on v11.5 and v12. Free upgrade to latest cloud-only version…
- December 2025: Hard end-of-support date for current customers on v14 and v15. Free upgrade to latest cloud-only version…
Choosing those dates can be tricky: we want to give customers lots of notice, and our cloud product isn’t (yet!) as terrific as we’d like. But we never get to perfection (see #1 above) and our investors are impatient. (SaaS cloud companies are worth a lot more than on-premise companies.) But we need to carve these dates in stone if we expect to make progress, so it’s critical to get full buy-in from the entire executive team.
We will, of course, send a barrage of notifications, technical notes, migration guides, and FAQs starting now. And let’s assume that most of these notifications will be lost, ignored, filed for later review, or misunderstood. We have to enlist our account teams to repeatedly re-re-communicate this to client-side stakeholders (and catch their inevitable requests for more time and special solutions.) This is a long march.
Create a Long-Running Cross-Functional Migration Team
Sales, Support, Professional Services and Marketing are all critical to a successful migration. Having product managers force-feed this to GTM simply won’t work. So we probably need a part-time cross-functional team that keeps things moving: identifying blockers; recruiting third party developers for custom connectors and workflows; staying ahead of major customer escalations; re-re-re-distributing technical materials that recipients keep losing; maintaining a notification cadence so no one can claim to be surprised. This is hard because most of the benefits accrue at the end, and our part-time team members have day jobs focused on current-quarter results.
We should provide a monthly update to the exec team with migration trend lines, info on upcoming cohorts, sample notifications, and expected customer escalations.
Find Ways to Celebrate Progress
This can feel grim and thankless. Plan celebrations each time we hit a milestone. Be effusive with our praise of Customer Support/Success. Make “We’ve upgraded 25% of our customer base” t-shirts.
Plan to Fire the Last Stragglers
Not everyone is going to move. I always see a few laggards; technically blocked customers; companies that want to milk their perpetual on-premise license for another decade; cash-strapped or technically underpowered accounts; and a few huge banks that treat their software vendors as custom development shops. So let’s have that C-level discussion now, rather than 3 years from now.
When our non-negotiable end-of-support date finally arrives, do we have the stomach to drop 20 accounts that represent 4% of total revenue in order to free up 90 engineers and designers? If we let customers run unsupported old on-prem versions, can we realistically provide zero support and zero updates and zero fixes when something breaks? Do we have custom development partners willing to maintain old stuff (and would we share source code)? When we hear that StragglerCorp is threatening to buy from the competition, can we wave goodbye?
Our goal is to speed up the overall selling process (by selling the identical bits to every user, eliminating options, and putting everyone on the same multi-tenant release); boost profitability and investor multiples (multi-tenant SaaS is a license to print money); shift Engineering to new winning products; and reduce implementation time / support overhead. We have to value that much more than our straggler group, or we’ll fail at the very end.
Sound Byte
Major migrations and other disruptions of our installed base are a big challenge. It’s easy to focus on the (serious) technical milestones, but most of the friction is with internal stakeholders and heavily invested customers who carry the short-term costs. We need realism, clear goals, and an iron-clad commitment from the executive team if we hope to make it work.
bird photo credit: https://www.flickr.com/photos/usfwsmtnprairie/13893615765/