How to Replatform a Software Company Safely

How to Replatform Before the Old Product Wins

Replatforming a software company requires more than building a replacement. Leaders must move data, customers, traffic, operations, revenue, and organizational attention while both platforms remain consequential.

The transition needs explicit gates for data parity, customer readiness, operational support, financial exposure, cutover, rollback, and final retirement. Without a retirement gate, the old product can consume every resource intended for the new one.

The difficult part is the middle

Before the migration, the old platform is authoritative and the new one is a project. After the migration, the new platform is authoritative and the old one is gone.

The middle is harder. Both systems matter. Customers are in different states. Teams support two paths. Revenue can slow while users upgrade. Sales may wait for a clearer story. The new platform has less production history, but the old one cannot support the future.

Robert LoCascio calls this the death zone in episode 106. He recalls moving LivePerson customers to LiveEngage after shifting most engineering attention to the new platform.

The metaphor captures the pressure. It should not become permission to ignore customer protection or evidence.

flowchart LR
    A["Legacy platform is authoritative"] --> B["New platform built behind clear contracts"]
    B --> C["Dual operation and data migration"]
    C --> D["Customer cohorts and production comparison"]
    D --> E["New platform becomes authoritative"]
    E --> F["Legacy writes and workflows stop"]
    F --> G["Legacy platform retired"]

Every arrow needs a measurable gate. Time alone is not a gate.

Establish the reason before the architecture

A replatform should solve an irreversible constraint, not express general dissatisfaction with old code.

The constraint may be scale, security, regulatory isolation, product model, deployment speed, data architecture, channel support, cost, or the inability to deliver a strategic capability.

Write the constraint in operational terms. If the old system cannot support asynchronous messaging across new channels without a redesign, say which channels, traffic, latency, data, and customer needs make that true.

Then write the conditions that would disprove the need for a full replatform. A focused replacement or compatibility layer may be safer than rebuilding the company around a new core.

The burden is higher when the decision consumes most engineering capacity or requires customers to change.

LivePerson shows the company-level cost

LivePerson's 2015 annual report described LiveEngage as its enterprise cloud platform for online and mobile messaging.

The 2016 annual report said business revenue decreased 8 percent, from $223.8 million in 2015 to $206.5 million in 2016. The filing linked the decline partly to rapid migration from the old platform, delayed upsells, customer preference to complete upgrades before expansion, and cancellations.

The 2018 annual report said the migration was completed in 2017 and the legacy offering reached end of life in the second quarter of that year. It attributed the later increase in business revenue partly to renewed selling after the migration.

Those filings do not prove that every decision was optimal. They establish the operating pattern: migration absorbed commercial attention, affected revenue, ended the old offering, and was followed by a new selling phase.

Separate company commitment from technical irreversibility

LoCascio says he burned the bridges by committing engineering resources to the new platform.

Organizational commitment can be useful. A transition will fail if every difficult quarter sends the company back to the legacy roadmap.

Technical irreversibility should be delayed. Keep data recoverable. Preserve a rollback path. Use compatibility layers where they protect customers. Do not delete the source record before the new one has proven authority.

The company may need an irreversible strategic decision and reversible execution steps.

That distinction turns courage into a control system.

Define the authoritative source at every phase

A migration fails when both systems can change the same record without a clear authority.

At the beginning, the old platform owns reads and writes. During dual operation, the company may replicate changes and compare results. Later, the new platform owns reads. Then it owns writes. Only after the old paths are unused should they be removed.

Stripe's engineering account of online migrations at scale describes that sequence for a production data model. Stripe dual-wrote to old and new tables, moved reads, moved writes, and then removed old data. It used incremental rollout and production comparison to catch mismatches.

The same logic can inform a company platform transition even when the units are larger.

The table does not imply one universal implementation. It makes authority explicit.

Move customers in cohorts

Customers are not interchangeable records. They have integrations, permissions, data volume, workflows, contracts, regions, support expectations, and tolerance for change.

Group them by migration risk. Start with customers who can surface real problems without exposing the company to its largest consequence. Keep a representative set. Do not call a cohort successful only because the easiest users moved.

Each cohort needs entry and exit criteria. Entry may require compatible integrations, trained support, a migration rehearsal, data validation, and a customer owner. Exit may require feature use, error limits, reconciliation, customer signoff, support stability, and no unresolved high-severity issue.

The few customers who cannot move need a named exception decision. An exception cannot remain an indefinite unofficial platform.

Fund dual operations honestly

During the middle, the company pays for both platforms.

The old system still needs security, availability, data integrity, and customer support. The new system needs development, migration tooling, observability, reliability work, and adoption support.

Pretending the old product needs no investment can create a preventable incident. Allowing it to retain a full innovation roadmap can starve the replacement.

Create a separate legacy budget with an explicit purpose. It funds safety, contractual commitments, critical defects, migration, and retirement. It does not silently reopen the strategic decision every quarter.

Track the cost of delay. Include duplicated infrastructure, duplicated support, migration engineers, opportunity cost, customer credits, sales friction, and the risk of maintaining two authorities.

Protect the customer before the date

The shutdown date matters, but the customer experience before it matters more.

Customers need to understand why the change is occurring, which behavior changes, what they must do, how data moves, which integrations break, where they can test, who owns the migration, and what happens if they miss the date.

The new platform needs a comparable service-level and incident model. A feature-complete checklist is not enough if operations cannot diagnose or recover the new system.

For a public company, financial and risk disclosure creates additional duties. The E106 article offers an operating framework, not securities, legal, accounting, or disclosure advice.

Decide the point of no return in advance

The point of no return should be a set of conditions, not a founder's mood.

It may include a threshold of migrated recurring revenue, zero unresolved critical data mismatches, stable production performance, trained support, completed regulatory review, tested rollback, customer notice, and an approved plan for remaining exceptions.

The final retirement gate should include proof that no material read, write, job, integration, report, support tool, or customer process still depends on the legacy platform.

After that gate, stop dual writes, archive the required records, remove credentials, close interfaces, update documentation, and watch for hidden traffic.

Removing the old system is part of the migration. Leaving it dormant but reachable preserves risk.

Communicate losses without pretending they are wins

A replatform can reduce revenue, slow new sales, create customer frustration, and consume years of work.

Leaders should describe those costs plainly. A short-term decline does not prove the strategy is wrong. Calling every decline a planned investment does not prove it is right.

Publish the milestones that matter, report misses, and distinguish migration effects from unrelated business problems. Make the recovery thesis falsifiable.

LivePerson's filings are useful because they connect migration to revenue effects and later completion. The founder's death-zone story adds the internal experience. Neither should be converted into a universal success formula.

The operating test

A company is ready to replatform when it can answer six questions.

What constraint makes the old architecture unacceptable? What source is authoritative in each phase? How will the company prove data and behavior parity? Which customers move in which order? How much dual operation can the company fund? What exact conditions retire the old platform?

If the last answer is missing, the legacy system will continue to negotiate for its own survival.

The goal is not to destroy the old product. It is to move every responsibility that still matters, prove the new authority, and close the old path deliberately.

Read the [[LivePerson Company Profile|LivePerson company profile]] and [[Robert LoCascio on KID Company, Uare.ai, and Building the Next Version|Robert LoCascio on KID Company and Uare.ai]] for the source context.

AI assisted with research organization and drafting. Dalton Anderson remains responsible for the analysis and publication decision.