Switching support platforms? Don’t migrate your old problems.

I’ve noticed a recurring trend in early calls with customers evaluating Plain as their new (and improved 😉) Support platform. I’ve even given it a name. The Jenga Tower problem.

The Jenga Tower problem

Hopefully, right now you’re picturing a late stage Jenga game. When you have the wobbling tower of blocks and the game has become less about ‘how do I make this difficult for someone else’ and more about ‘how do I not topple this thing’.

Support functions often end up in a similar precarious state. Lots of historical decisions piled on top of a fragile foundation, day to day you’re aware of the frustrations that today’s set up causes. But it’s not until you really begin thinking about knocking it all down that the bigger picture comes into focus and you start internally screaming…

Why import questions don’t give you a plan

At which point, the conversation often begins to steer towards how to handle importing. How easy is it? How long will it take? Can we run both systems in parallel while we’re setting up?

On the surface, these questions can seem like a good way of scoping what the migration will entail. The problem is that answering them doesn’t provide your migration with any structure. The structure is given by the questions with no strictly defined edges. What do we bring over, what do we build, and will these foundations still hold up in 6, 12, 24 months and beyond?

Reframing the conversation around an MVP

These are the questions with no easy answers. So I find it useful to reframe the conversation. Asking about what their ideal MVP of a new Support foundation looks like.

In doing so, getting away from the conversation being about a specific plan, and into setting out the criteria that will make their Plain workspace usable as a foundation.

Starting from a clean slate

One team I worked with recently found that the answer to this question was bringing almost nothing across from a setup that half a dozen people had contributed to over four years.

They took full advantage of the opportunity to design their system from the ground up with full control from day 1. So chose to move their history into a separate archive workspace, and start with a clean slate in production.

What’s worth bringing over, and what isn’t

Another recurring finding is that it is of course useful to bring over conversation history and internal notes. It’s important context, and can influence how a live conversation gets handled.

But most of the enrichment built on top of those conversations carries the mental load that you’re trying to get away from. Custom fields that reference products that have been renamed, or deprecated entirely. Help center resources that were written by humans, for humans that have no clear owners, aren’t regularly updated and contradict each other.

All of this in turn causing increased ticket volume from customers. Especially those using AI agents to find answers because there is no clear source of truth.

Testing whether the foundations will hold

But the question of whether the foundations will hold up, that’s trickier to answer. So it’s the question that stays open longest as the evaluation continues.

It can’t be answered in the abstract, so I’ve taken to asking our customers to name a single thing they expect to need in a year and tell me where it would live in the new setup. It feels somewhat uncomfortably like the ‘where do you see yourself in 5 years’ interview question. But if they can define it, we then build it in a sandbox workspace and run it end to end before a single (real) customer touches it.

It’s worth picking your test cases from a few different eras too, the older ones usually have some nuance hiding in them. And they can help you anticipate questions from returning customers who may not be up to date on where your product is today.