What Happens to Support When You Migrate Systems
Every system migration has an assumption baked into the timeline: that support will keep running normally while everything underneath it changes. That assumption rarely survives contact with reality. Somewhere between decommissioning the old system and fully standing up the new one, there’s a stretch where your team is doing double duty, and customers don’t know or care that you’re in the middle of a transition. They just want their question answered.
We saw this play out clearly with a biotech firm that had just gone through a corporate split. They weren’t just adopting new software. They were standing up an entirely separate operation, which meant migrating not just data, but the support function itself, from scratch.
The gap nobody plans for
When you migrate from one platform to another, there’s an in-between period where the old system still has to keep functioning for existing tickets while the new system gets built out. That means your team is often working two systems at once. They’re closing out old tickets in the platform you’re leaving, while trying to learn and adopt the platform you’re moving to. Meanwhile, the data that actually needs to move, customer history, past interactions, documentation, has to get from one place to the other without getting lost, duplicated, or corrupted along the way.
This is a pain point almost anyone who has been through a migration recognizes immediately. It’s not a hypothetical risk. It’s the default experience of migrating any system that support depends on.
Why this is worse for support specifically
Some parts of a business can pause during a migration. Support can’t. Customers keep emailing, keep calling, keep expecting answers, regardless of what’s happening on your end. So while other departments might be able to freeze certain processes during a cutover, support has to keep operating at full capacity while its own foundation is being rebuilt underneath it.
For this biotech team, that challenge came with an added layer of sensitivity. Their business sits close to healthcare, dealing with test kits and results, which meant they couldn’t afford sloppy answers just because they were mid-migration. Customers asking about their test results don’t have a lower bar for accuracy just because your team happens to be switching CRMs that month.
Starting from zero has a hidden advantage
Here’s the part that’s easy to miss when you’re in the middle of a migration and it feels like nothing but a headache. If you’re moving to a new platform and you don’t have an existing knowledge base to bring with you, you’re not stuck rebuilding something broken. You’re building something correctly for the first time.
Most businesses that have been on the same CRM for years accumulate a knowledge base that’s grown organically, unevenly, and without much structure. Articles get written when someone has time, not according to any real plan. Old information doesn’t get retired. Formatting is inconsistent because five different people wrote it over five years. A migration forces a reset, and while that’s disruptive in the moment, it’s also a rare opportunity to build support infrastructure the right way from day one, rather than trying to untangle a decade of accumulated mess.
That’s exactly what this team did. Rather than treating the new Salesforce Service Cloud instance as just a place to move old tickets, they used the migration as the moment to build a knowledge base designed specifically to support an AI agent from the start. How to Ground an AI Support Agent in Your Own Knowledge Base covers how that foundation actually came together.
What to prioritize during the transition
If you’re in the middle of a migration like this one, or about to start one, a few things matter more than they might seem to in the moment.
First, resist the urge to just recreate your old knowledge base as-is in the new system. A migration is your best chance to fix what wasn’t working, not a reason to preserve it out of convenience. Second, get clear on what your most common support questions actually are before you start writing new documentation. You want to prioritize the volume drivers, not just whatever’s easiest to document first. How to Audit Your Support Data Before Adding AI is a useful exercise to run in parallel with your migration planning.
Third, don’t wait until the new system is fully live to think about automation. If you know you’ll eventually want an AI agent handling routine questions, building your new knowledge base with that end goal in mind from day one saves you from a second rebuild down the line.
The payoff on the other side
For this team, the migration wasn’t just a lateral move from one system to another. It became the foundation for something meaningfully better than what they had before. Once the new Service Cloud instance and knowledge base were in place, they layered an AI agent on top of it, one that could answer routine questions directly from that knowledge base and escalate anything sensitive to a person. Within the first version of that build, the agent was handling around 40 percent of inbound inquiries without human involvement.
That result didn’t happen despite the migration. It happened because the migration forced a level of intentional rebuilding that most businesses never get around to doing on their own timeline. If you want a clearer picture of what that AI layer actually looks like once your foundation is solid, How Your AI Agent Actually Finds the Right Answer is a good next read.
The takeaway
A system migration will disrupt your support operation in the short term. That part isn’t avoidable. What is avoidable is treating that disruption as pure cost. Handled well, a migration is the one moment your team gets a legitimate excuse to rebuild support infrastructure the right way, instead of patching around years of accumulated shortcuts.
If you’re staring down a migration and dreading what it’ll do to your support team’s day-to-day, it’s worth reframing the project. You’re not just moving data from one place to another. You’re getting a rare chance to build the foundation you actually want.
Listen to the full podcast episode here.