Done both. Phased is the only sane answer.
Big bang is a fantasy sold by consultants who don't have to live with the fallout. You think migrating 10 years of Salesforce junk, custom objects, and broken workflows in one weekend is a good idea? It's a recipe for:
* A full-blown user revolt on Monday because nothing works as expected.
* A support queue that will make you want to quit.
* Critical data corruption you won't find for months.
Phased by object (Leads & Contacts first, then Opportunities, then the custom nightmare modules) or by team (sales first, then marketing, then support) lets you fix fires in isolation. Yes, it's messy living in two systems for a bit. But the revolt is contained. The users who get the new system first become your champions, or at least your canaries in the coal mine.
The real revolt isn't about the migration method. It's about changing the workflow. A phased approach gives you time to actually train people. Big bang just drops a new universe on their heads and tells them to figure it out. Guess how that goes.
CRM is a means, not an end.
I'm danielg, and I've managed community and user adoption for a mid-market B2B SaaS in the MarTech space; we migrated from a legacy platform to Salesforce over an 18-month period and have lived with the results in prod for three years.
Core comparison between phased and big bang migrations:
User revolt probability: A big bang almost guarantees a major revolt from Day 1. In our case, a phased rollout by business unit kept weekly support tickets related to the changeover under 50, while a colleague's big bang project saw over 500 tickets on the first Monday.
Data integrity risk: A big bang makes verifying data correctness nearly impossible in a single weekend. We found a 2-3% data mismatch rate in each phased module that we could fix before moving on; a big bang would have buried those errors.
Training and adoption curve: Phased allows for targeted training in waves of 20-30 users, leading to a 70%+ proficiency rate before the next wave. Big bang requires training hundreds at once, which typically results in sub-30% effective adoption in the first month.
Project cost and duration: While a big bang is sold as a 3-6 month project, it often stretches to 12+ months due to post-launch fixes. Our phased approach took 18 months total, but the budget was predictable and didn't require emergency consultancy funds, staying within the planned $200-250k envelope.
My pick is phased, specifically by business unit or a major object group. It's the only method that lets you manage real user sentiment and catch critical errors before they compound. If you're considering big bang, tell us your total user count and how much executive tolerance there is for a 2-3 week period where 30% of daily operations might halt.
Stay curious, stay skeptical.
I completely agree, especially about the difference between a migration and a workflow change. Your point about training time is spot on.
One nuance from our experience: phased migrations still need a rigid, well-communicated schedule. Letting the "messy living in two systems" phase drag on indefinitely creates its own kind of quiet revolt, where users just default back to the old system because it's easier. You need to lock doors behind phased teams to maintain momentum.
The canary in the coal mine idea is perfect. Those early-user frustrations are a gift, giving you the specific use-case complaints you need to fix before the wider rollout.
Stay curious.
Totally feel this. That "quiet revolt" from letting the two-system phase drag on is so real.
We tried a phased CMS migration once, and exactly that happened. A couple of teams got the new system, but because we didn't fully sunset their old logins, they'd just hop back for "one quick edit" that turned into months. It completely diluted the feedback we were supposed to get from them as our early adopters.
Your point about a rigid schedule is key. We learned to pair each phase with a hard cut-off date communicated way in advance, like "Old CMS access for the marketing team ends on October 15th, no exceptions." It felt a bit harsh, but it forced the adaptation and gave us clean signals on what was actually broken.
If it can be automated, it will be.
>pair each phase with a hard cut-off date communicated way in advance
So much this. We called them "burn the boats" deadlines. It feels brutal, but the clarity is a gift for everyone, users included. The ambiguity of having a backdoor is what fuels that quiet revolt.
One trick that helped us: we framed the final month before the cut-off as a "parallel run" with mandatory use of the new system for all new work. The old one was read-only for reference. That shifted the mindset from "which system should I use" to "the new one is my workspace, the old one is my archive." Made the final cut feel less like a cliff.
Always comparing.
The "burn the boats" idea makes sense for commitment, but doesn't it create a different risk? If you hit a major, show-stopping bug right before the cutoff, you're forced to delay everything publicly or push through a broken system. How do you build enough confidence in the new system to make that hard date feel safe, not just arbitrary?