The Purple Button
Why Feature Parity Kills Replatforming Initiatives
I’ve carried this lesson with me for 20 years across three different companies; and I am watching the pattern play out in real time across so many industries. Now even more than ever, modernizing a well adopted legacy solution is critical to allow companies to stay competitive and leverage the benefits of AI both internally and market facing.
There’s an innocent question that shows up in almost every replatforming initiative; and it reveals everything about whether you’re actually modernizing or just recreating the past.
“Where’s the purple button from the legacy system?”
The purple button was literally a button in the top right corner of an industrial manufacturing solution I built many years ago at one of my previous roles. When we started modernizing the platform, someone asked that question. And that question, seemingly harmless, represents the entire reason replatforming initiatives fail. It’s not actually about the button. It’s about what the button represents: the commitment to build the future by perfectly replicating the past.
How the Parity Trap Works
It starts with the right instinct, we’re rebuilding our platform, so we need to make sure customers don’t lose anything. Feature parity rather than functional parity becomes the rule by which every line of code is measured. Everything that existed in the legacy system will exist in the new system; nothing lost. Then you start building and realize that to achieve parity, you need to recreate years (even decades) of accumulated features, workflows, customizations, and yes, odd design choices like that purple button in the top right corner.
Here’s what happens. Months 1 through 3, engineering is confident they’ll rebuild the core in three months and add parity features in another three. Months 4 through 6, stakeholders start asking questions; where’s X feature; that’s in parity phase 2; and you repeat this 50 times as the questions compound. Months 9 through 12, you’ve shipped something that looks modern but feels like legacy; same structure; same navigation logic; same workflows; different skin. By month 12, you’ve spent your entire engineering budget on replication with zero on differentiation. You’ve built a museum exhibit of your own past, just with better lighting.
Why This Happens
The parity mindset comes from a place of respect for customers and caution about churn; it sounds good in theory. We don’t want to break anyone’s workflow; we’re modernizing the platform, not changing the product. But this creates a logical impossibility… you can’t modernize something into being fundamentally the same. Modernization means reimagining; it means asking what problems you solved in 2012 that maybe (likely) don’t need solving the same way in 2026; it means making different trade-offs. Sometimes that means the purple button moves; or disappears.
When you commit to parity, you’re actually committing to not modernizing… you’re committing to replicating. And replication is exhausting, expensive, and underwhelming.
The trap has two teeth. Engineering trap: you burn 12 months rebuilding things that don’t matter so you never ship the things that do. Customer trap: you attract customers who want the same thing but modern; they don’t actually want modernization; they want the security blanket of sameness; these customers will never choose to migrate willingly; you’ll have to force them… you’ve fixed essentially nothing. You’ve actually created the perfect storm of increasing complexity.
The Replatforming Nightmare
I watched this play out at my previous companies, the pattern was so consistent it became predictable. Year 1: we’re modernizing the platform. Year 2: we’re rebuilding with modern architecture, and engineering spent the year recreating legacy features. Year 3: we’re creating a smooth migration path, which translates to we’re not done yet and legacy customers are getting angry. Year 4: we’re sunsetting legacy, which translates to we’re forcing migration because we can’t afford to maintain both platforms. Year 5: customer churn, leadership changes, new direction… or some flavor of this.
The nightmare isn’t building a new platform; the nightmare is building a new platform that doesn’t feel new while spending enough time and money to build three genuinely new platforms.
Breaking the Trap
Here’s a different way to think about this, instead of asking, “how do we rebuild legacy?”, ask what problem do our customers have that we’re not solving today. Because every company has one; a gap between what the current platform delivers and what customers actually need.
When you focus on that gap, you’re not building parity, you’re building differentiation. And differentiation is what makes customers want to migrate, not what makes them feel forced to. Here’s what changes… when a customer wants to migrate because the new platform solves something they’ve needed for years, they don’t resent the migration, they embrace it, they sign a new contract on mutual terms, not legacy terms. Clean slate, new relationship.
This approach delivers something parity never can. It’s differentiated, nobody else in the market does this the same way. It’s worth migrating for, customers choose to migrate because they want what the new platform offers, not because you forced them or promised parity. Precisely the reason your customers go to RFP in the first place, by the way. This approach avoids much of the replatforming nightmare, when customers migrate willingly, and they sign a new contract on mutual terms. As a result, the organizations is not bound (and constrained) by everything legacy had. It lets engineering innovate… instead of spending 12 months recreating purple buttons, engineering spends 12 months building new capabilities customers didn’t have before.
What This Means for Product Leaders
If you’re leading a modernization initiative, ask yourself these questions. Are we modernizing or replicating? If the answer is we’re rebuilding legacy with new tech, you’re in the parity trap, modernization means reimagining, not replicating. Would customers migrate for this willingly? If the answer is only if we force them or because we promised parity, you’re building the wrong thing… build something worth migrating for. Are we spending engineering effort on differentiation or replication? Track where your engineering cycles go, if 80 percent is recreate what we had and 20 percent is build what’s new, reverse those numbers. Build something so valuable that the journey from legacy to new feels like progress, not disruption. This attracts customers who want to move forward, and it makes the migration itself part of the value story
The Hard Truth
Here’s what nobody wants to say out loud in a modernization meeting… some legacy features don’t matter, some legacy workflows were mistakes, some legacy choices were made by people who left the company a decade ago. When you commit to parity, you’re committing to carrying all of that forward into your future, forever.
When you commit to differentiation, you’re saying we’re going to make different choices… some people will dislike that, and that’s okay. To stay relevant and be disruptive, the mindset must be that we’re building for customers who want the future, not customers who want the past with better UX. This is hard as most good things are. It’s easier to promise parity, it’s easier to say we’ll have everything legacy had, just better… it sounds safe. You don’t have to waste years of innovation budget while you watch your NPS die to learn this.
Moving Forward
If you’re in year 2 or 3 of a replatforming initiative and you’re exhausted, frustrated, and wondering why customers aren’t excited, ask yourself this, did we break the parity trap or are we caught in it?
If you’re caught, it’s not too late to change course, stop rebuilding legacy, and start building the future… let customers choose whether they want to go with you by making the choice easy.
The purple button can stay in legacy, where it belongs. Your job as a product leader isn’t to perfectly replicate what came before, it’s to build what comes next. And that requires the courage to let some things go. Because the real replatforming nightmare isn’t building something new, it’s building something new that doesn’t feel new while spending enough time and money to build three genuinely new platforms. Move the button, or remove it entirely, but don’t spend 12 months recreating it perfectly so that you can continue to provide imperfect workflows.
.