When is a legacy to SaaS migration worth it?

It is worthwhile when it moves a liability you cannot discharge onto a party whose survival depends on discharging it. It is a waste if the liability simply moves to a new address.

What costs does SaaS pricing typically cover?

SaaS pricing addresses the costs of running the system, such as hardware, licences, and patching. It does not typically cover the risk of being answerable for the system.

What are the signs a system has become a liability?

Signs include rising costs for a static system, a support end date within 18 months, or an audit finding that cannot be closed. Integration demands may also outgrow the platform.

When Legacy To SaaS Migration Is Worth It | Legacy Software Modernisation

The Qnetex ERP system is a useful place to begin, because the project Intercept ran for it left the business logic alone. Intercept reported that moving the system off its own premises and onto Azure simplified deployment and let the company grow faster. The software carried on doing what it had always done. What changed was who carried the burden of running it.

That is the test, and everything below depends on it. Legacy to SaaS migration earns its place when it moves a liability you cannot discharge onto a party whose commercial survival depends on discharging it. It wastes money when the same liability arrives at a new address with a subscription attached to it.

Naming the burden a subscription can actually take

Every legacy system carries two costs, and software that adds the two together lose their argument somewhere in the following quarter.

The first is running the thing: hardware, licences, patching, and the people who know where the bodies are buried. The next point is being accountable for it: the audit finding no one can close, the component no one can upgrade, the specialist who departs and takes the only working knowledge of the overnight batch schedule with them.

SaaS pricing speaks to the first of those costs. The case for the move gets made on the following point. That mismatch decides whether the software stays intact, because the saving arrives in a place the business case never mentioned.

Abbacus Technologies, in SaaS Migration Costs: Legacy to Cloud-Based Product, sets out what a migration buys: assessment and planning, data migration, refactoring or re-architecting, integration, training and change management, testing and quality assurance, and the ongoing subscription and operational cost. Each cost on that list is a price you will pay. The reason to pay it sits somewhere else entirely, and the liability is the thing that has to be named.

State the liability in one sentence before a platform is discussed, and name the party who has it today and the party who has it after the contract is finalised. If those two identifiers are the same, the migration has removed nothing.

State the liability in the singular, as one sentence a director can act on.
Identify the current holder by role.
Specify the future proprietor by the contract clause that binds them.
Set the date on which the liability becomes unacceptable, and let that date drive the timetable.
Refuse the migration when the only benefit a user can state is that the destination is newer.
Agree in advance whose signature ends the debate.

Six conditions that have to hold at once

One condition is an argument. Several together are a case. A migration is worth authorising when most of the following hold at the same time, and worth postponing when only one does.

The recurring bill climbs while the system stands still. When the annual cost of keeping a system alive rises and the system itself does nothing new, the money pays for its existence.
The vendor support horizon falls inside your planning window. Cleveroad's guide to migrating legacy systems to the cloud manages a support end date inside the next eighteen months as one of the signals that a system has turned from asset into liability. That horizon fixes the date on which the decision is no longer optional.
Integration demand has outgrown the platform. Cleveroad records product teams asking repeatedly for interfaces the current stack cannot provide, including REST APIs, webhook triggers and identity federation. That pattern makes the platform the constraint on the product roadmap.
The audit record cannot be closed within the current system. A finding you cannot remediate is a liability with a date attached to it.
The estate already has applications that no user uses. Cleveroad reports that audits commonly uncover unused applications and duplicates of functionality another tool already provides. Clearing those out before anything migrates lowers both bills.
The next hardware refresh costs about what the migration costs. When the capital decision and the migration decision land on a similar figure, migration changes the shape of the cost as well as its size.

Three or more of these arriving in the same quarter is the usual trigger. Any one of them on its own is a reason to write the liability sentence and wait.

Seven routes, each with what it keeps and what it exposes

The word migration covers seven different bargains. They differ in what each one makes you manage, and that difference matters more than the effort each demands. Cleveroad sets them out in this sequence:

Rehost puts the application onto cloud machines without touching the code. It keeps the behaviour and the test evidence, and it gives you the same operational shape at a new address.
Replatform keeps the application's logic and replaces self-managed components with managed ones, such as a managed database or a managed message queue. You maintain a partial redesign that no one on your team wrote.
Refactor keeps the business function and changes the integrations, moving authentication to managed identity, file storage to object stores, and batch jobs to serverless functions. You pay for a stretch of engineering work before any benefit becomes visible.
Rearchitect keeps the business outcome and discards the architecture, turning a monolith into services and request-response into events. It carries the highest execution risk of the seven, because the replacement gets built while the old system still has to work.
Repurchase keeps almost nothing and buys the function back as a subscription. It risks the customisation that may have been the only reason users valued the system.
Retain keeps everything and changes nothing. You keep the next refresh and the support horizon you already know about.
Retire stores no data and ends the payment. You have nothing to manage, provided the function has genuinely gone.

Convotis, in its guidance on moving from legacy to SaaS, draws the conclusion that follows from that list: the change lands on architecture, governance and the financial model at the same time, and the shift from capital spending to operating spending has to be measured in new ways. A ledger built for hardware purchases will not show you whether a subscription is working.

What a supplier has to be able to evidence

The commitments are the product. Read them as a specification, because they are what you will rely on in the next year, once the migration team has gone.

The commitments below come from Cirro's G-Cloud 14 listing for legacy application migration:

Data storage and processing stay in the United Kingdom, and customers control the location.
Encryption of all physical media at rest, and a stated approach to data sanitisation before storage is reallocated.
Penetration testing at least every six months, and an access restriction review at the same frequency.
Management interfaces reachable only by named, security-vetted individuals through a two-factor authenticated tunnel, with every connection logged and audited.
Repeated failed authentication attempts locking the account automatically and raising a notification.
User audit data, supplier audit data and system logs retained for at least twelve months.
A designated executive in charge of service security has certification to ISO/IEC 27001.

Put that list beside your own system. Where you cannot evidence most of it today, the gap is what you are buying, and the migration answers a real problem. Where you can evidence all of it, the subscription needs a different justification.

Where the liability sits after cutover

A contract moves a great deal, and it cannot move everything. Convotis makes the point that the shared responsibility model means the provider secures the infrastructure while the customer stays accountable for governance, compliance and data protection. Roles, audits, penetration testing and identity management remain your work, and they remain your work at the point when the system is least familiar to the people running it.

Convotis also flags the financial side, where subscription charges, data volumes, per-call API billing and add-on modules can produce costs that never appeared in the estimate. The remedy it proposes is licence management, forecasting and process-level return on investment, reviewed by a board that brings IT, finance and compliance into the same room on a regular cycle. The four families of measure, strategic, financial, operational and compliance, are part of three different functions inside most organisations, which is why the review board has to be a standing arrangement rather than an occasional meeting.

How the work is sequenced so the old system keeps earning

Mastery's legacy to SaaS implementation playbook argues that the risk in these projects sits in delay and in the fear that produces it, with a vague vision, unclear ownership and key processes held in people's heads. The remedy is a crawl, walk, run process that avoids a single disruptive cutover, starting with core functions, stabilising them, and expanding capability in stages.

Mindinventory's SaaS migration guide explains the parallel model, in which the legacy application and the SaaS version run side by side while users move across gradually and behaviour is compared on both sides until the old system is retired. That arrangement gives the flow of operations its shape for software that cannot afford an outage.

The series of steps resulting from both is short:

Migrate one module or process first, chosen for low consequence if it breaks.
Run both systems in parallel and compare what each produces, treating any difference as a defect to be explained.
Move users across in groups, with a designated user answering questions for each group.
Keep the old system restartable until the new one has carried a full business cycle.
Retire the old system only against a written test of what finished means.
Record what the pilot cost, because the estimate for the rest of the estate will be built on it.

The knowledge that has to move with the system

Mastery states the problem clearly: processes that live in people's heads and in spreadsheets do not survive a migration, because there is nothing to migrate. The software is the easy part. The rules that were never written down are what break at cutover.

Abbacus Technologies includes training and change management among the real costs of the move and explains the result of skipping it: productivity loss, errors and slow adoption. Add to that the fact that the people who know the exceptions are the same people the programme will ask to accept the new system. Bring them in at design, when their objections are cheap to answer. Leave them out, and you meet them at cutover, when those objections are expensive.

Measuring the result twelve months after cutover

Go back to the sentence written before the platform was chosen. Ask whether the supplier is now accountable for the burden named in that sentence, by contract, with a date attached, twelve months after the new system has carried a full business cycle.

Five questions settle it:

Has the recurring charge for the old system stopped entirely?
Can you point to the audit finding and the date it was closed?
Can the product team add the integration it was asking for without a procurement cycle?
The monthly bill shifts when usage shifts, and a user manages that number.
Does your organisation have a designated staff member who manages the new system's governance, and can they find their counterpart at the supplier?

Where the answers line up, the migration did what the Qnetex case shows: it left the business logic alone and changed who carries the burden of running it. Where they do not, the programme bought a newer address for the same liability, and the next refresh will present the same decision with less time in which to make it.

When Legacy To SaaS Migration Is Worth It