Replacing a software product: planning a period with two versions

When replacing software that already serves customers, the budget extends beyond building the new version. Decide how the old version remains supported, who moves first, where work is recorded and what happens if the trial disappoints. A planned transition allows learning before moving everyone, but creates additional work that needs funding and boundaries. Request a proposal covering how the two versions coexist and the conditions for ending that overlap.

What does the FreshBooks story illustrate?

An Inc article about FreshBooks describes a separate product called BillSpring before it became the new version. The company’s rebuilding announcement describes a product developed from the ground up using customer feedback. This is a historical transition choice, not evidence that every company should launch a secret brand or operate two products for an identical period.

Our interpretation of the draft is that learning and continuity need funding together. A team building a replacement does not automatically stop receiving enquiries and defects from the existing product. A plan containing only new screens leaves that work to emerge as delay or extra cost. You need not duplicate every product component: a defined user group or workflow can establish a boundary, provided everyone understands what changes and what remains in the existing system.

Set a clear trial boundary

Start with the outcome to improve: task completion, a missing capability or a limitation preventing expansion. Choose a group you can learn from without immediately generalising to all customers. Record which actions the new version supports and which it does not. Participants should understand which version they use and how to obtain help. A trial should not conceal a missing capability that affects real work.

In a hypothetical order-management system, you might begin with one order type for a defined group. Even then, decide what happens when an order requires an action available only in the old system. Will a person handle it, participation be restricted or the capability be added before the trial? That is a specification question. Do not leave support staff to discover it after customers have started using the replacement.

Decide where work is recorded

With two versions running, establish an authoritative source for every datum and operation. Duplicate writes without reconciliation rules can create different answers to the same question. Request a simple diagram showing who creates a record, who can update it and how changes reach the other version when necessary. If no synchronisation exists, state that explicitly and explain how outdated information will be kept out of operational use.

Also distinguish checking copied data from executing a real business action. Calculations can be compared without sending customers duplicate messages or performing an external operation twice. For each integration, specify which version may act and when that permission transfers. Include these ownership and transition decisions in the technology product specification. A working-looking screen does not establish that an action occurred once and in the correct place.

Budget for the overlap

Request separate estimates for new development, essential fixes to the old version, support for both, data transfer and discrepancy checks. Assign responsibility for deciding which change requests enter each version. Otherwise, the team may implement every capability twice without the plan recognising that effort. New requests need not all reach the old product, but existing commitments require explicit decisions about how they will be honoured.

Set review points for expanding, extending or narrowing the trial. An extension should have a reason and cost rather than becoming an indefinite state without an owner. Ask what a delayed transition costs and what can be deferred without harming existing service. There is no universally correct transition duration: data scope, dependencies and usage frequency affect both the evidence available and the time needed to collect it.

A practical separation in our publishing tool

The Julius website publishing tool checks an article without publishing by default; writing to the content system requires an explicit publication mode. After writing, the procedure still requires a separate check of public pages. This is a documented separation between validation, change and outcome verification. It does not claim that we operated two customer systems in parallel or demonstrated savings from a product replacement.

The same principle can inform a replacement project: distinguish checked information, executed actions and confirmed outcomes. When presenting a comparison using trial data, identify what remains untested in the actual workflow. When a production action occurs, retain evidence linked to its version and case. This helps a product owner understand precisely what is known before approving another group’s move to the new system.

Plan reversal and retirement in advance

Returning to the old version must account for data created during the trial. Can it be transferred, which fields are unsupported and who checks for unfinished work? Do not call a change reversible merely because a URL or screen can be switched. Request a reversal exercise in a suitable environment, recording what can be restored and what needs intervention. Our guide to periodic process checks during migration extends verification beyond an ordinary working day.

If the replacement includes AI, separately define output-quality comparison and human approval; our guide to choosing AI developers supplies questions for the team. For a conversation with Julius about software development, bring the trial boundary and work customers must continue performing. Also request retirement conditions for the old version: completed data transfer, resolved dependencies and named service ownership. The overlap can then become a deliberate phase with an exit decision rather than an expense without one.