Salesforce Lift and Shift: Why It Sounds Safe and Rarely Works
Someone in your company is saying it right now. “We’re just going to lift and shift. Pull it out of the old system and put it in Salesforce.” It sounds like the conservative choice. No process change, no retraining, just a new platform under the same work.
On the latest Cirrius Talk: Salesforce at Scale episode, Cirrius consultant Matt Oesterlein described hearing that phrase at a former employer and the reaction it produced. “It stirred up a righteous anger in me that I can’t begin to describe.” His response to the person promising a Salesforce lift and shift was simple. “No, you’re not. Nobody’s ever done that.”
This post covers why a lift and shift migration to Salesforce almost never survives contact with reality, what actually transfers, and how to plan the migration so the platform change makes the business better instead of just newer.
The short version
- Nobody knows what “the whole thing” is. Years of undocumented exceptions, workarounds and spreadsheet shortcuts live in the old system, and none of them are in the configuration you plan to copy.
- The platform change forces process change. Moving from a substantially different system into Salesforce changes the process whether you planned for it or not.
- Copying the old process defeats the purpose. If the current process were good enough to preserve exactly, the migration would be a waste of money.
- Off the shelf is broad, not specific. Standard functionality works for any business, not necessarily for yours. Closing that gap is the actual work.
- Discovery is the cheapest hour you will spend. Skipping it moves the same conversation to after go live, where it costs three to four times more.
Matt Has Been the Client
Before Matt joined Cirrius, he was a full stack developer running IT for a home services construction company. He owned a system his team had built in house and he sat on the client side of a Salesforce implementation. He has argued for lift and shift from the inside and watched what happened.
That experience produced the line we keep quoting from the episode.
“If you’re doing a full lift and shift of a system that you built out in house, you better make sure you bring the whole thing.”
Matt Oesterlein, Consultant, Cirrius Solutions
The problem is that nobody knows what the whole thing is. That is the entire argument.
The Old System Is Bigger Than Anyone Remembers
Delivery Director Al Huerta called it the onion. Every business has layers nobody remembers building.
A system that has been in use for years accumulates process the way a house accumulates wiring. Each piece made sense when it was added. Nobody wrote it down. Here is what a lift and shift plan typically misses:
Bespoke customer processes
One big account got its own workflow.
Hover for detail
Bespoke customer processes
Matt noted this is common even in large organizations. That workflow lives in the old system as an exception nobody flags.
Approved workarounds
Somebody signed off on going off the reservation.
Hover for detail
Approved workarounds
And there they sit. The later you find them, the more catastrophic the surprise.
Oral tradition
The process lives in people’s heads, not a runbook.
Hover for detail
Oral tradition
Matt: “If you’re trying to translate the story of your entire business to another language, you’ve got to actually tell that story to somebody before they can tell you whether it’s going to translate well.”
The spreadsheet layer
A desktop full of shortcuts between the system and the work.
Hover for detail
The spreadsheet layer
Those are process too. A lift and shift plan almost never inventories them.
You cannot lift what you cannot see. And you cannot see it by looking at the old system’s configuration. You see it by asking people about their worst week.
A Platform Change Forces a Process Change
Al made the point that even a perfect process does not survive a platform change intact. “Coming from a system that was substantially different than Salesforce into Salesforce, just because you’re going through a platform change may force process change.”
That is not a flaw in Salesforce. It is the reason you are moving.
Matt’s challenge to the lift and shift crowd cuts to it: “If I want to lift what I’m doing and stick it somewhere else, then why are we changing?” If the current process were good enough to preserve exactly, the migration would be a waste of money. You are migrating because something about the current state does not scale, does not report, or does not connect. Carrying that forward defeats the purpose.
There is a second trap on the other side. Matt described projects where only the executive vision got built, and the day to day needs were not met, and projects where only the ground level got built and the executives ended up with old problems on a new platform. The migration has to hold both. Future proof the vision and keep the business running tomorrow morning.
Off the Shelf Is Broad, Not Specific
A related misconception drives a lot of lift and shift thinking. You are buying an enterprise platform, so the standard functionality should cover everything.
Matt’s explanation is the clearest we have heard. “The off the shelf functionality is so broad that it’s helpful in a general way, but not in a specific way. It works for any business, but not necessarily for your business 100 percent.”
Salesforce is the right foundation precisely because it is broad. The work of a migration is closing the gap between general and specific, and that gap is exactly the set of exceptions, edge cases, and customer specific processes that a lift and shift plan assumes away. Standardizing some of them will make people unhappy in the short term until the benefits show up. Skipping that conversation does not make it go away. It moves it to after go live, where it costs three to four times more.
How to Migrate Without Lifting and Shifting
Four steps that replace the lift and shift plan with one that works.
Pay for exploratory discovery first, with the team that will build. Matt’s recommendation from the client side. Discovery feels like money thrown away because the output is a plan, not software. It is the cheapest hours you will spend on the project.
Architect the meetings in two passes. Al’s method. First session: tell me everything you do today. Go away, recap it. Second session: now tell me about the unhappy path, the 20 percent, the exceptions. And then the scaling question. You do 25 appointments a day. If you did 500, where does this break?
Find a subject matter expert per area, not one person for everything. The person who has time for meetings is rarely the person who knows the process. Al’s advice: identify the people who actually do the work in each department and deputize them. Then have leadership fund their time, which Greg put at 15 to 50 percent of their calendar for the life of the project.
Build a working proof of concept before the real build. Model the whole process, exceptions included, in something your team can click through next to their current system. That is where the layers of the onion surface. We covered the POC approach in detail in Proof of Concept vs MVP: Which One Your Salesforce Project Needs.
Matt summed up the outcome from the client side. He has not found a case where a client needed extensive discovery, chose to fast track instead, and ended up satisfied. The ones who skip it always pay for it at the end.
Frequently Asked Questions
What does lift and shift mean in a Salesforce migration?
Lift and shift means moving an existing system’s data and processes into Salesforce with no process redesign. In practice the old system contains undocumented exceptions and workarounds that do not transfer, so a true lift and shift almost never happens.
Why not just replicate our current process in Salesforce?
Because the platform change itself forces process change, and because the current process is the reason you are migrating. Replicating it carries the old limitations onto the new platform and skips the standardization that produces the return.
How do we find the processes nobody documented?
Run discovery in two passes, happy path then unhappy path, with a subject matter expert from each department. Then put a working proof of concept in front of those people and let them compare it to how they actually work. The gaps they point out are the undocumented process.
We Migrate the Whole Thing
Cirrius Solutions runs Salesforce migrations that start with paid discovery and a working proof of concept, so the exceptions surface before the build gets expensive. You end up with a Salesforce system that fits your business, not a copy of the old one on a new platform.
Planning a move to Salesforce? Talk to us before anyone says lift and shift. And hear the full conversation with Matt and Al on Cirrius Talk.
