Paul A. Mohabir is head of IT at Transervice Logistics.
Getting a new platform live is an important milestone. It doesn’t necessarily mean the business is ready to let the old one go.
Sometimes that’s the right decision. Teams may still need historical records, certain services may need to remain available and a period of overlap may protect the operation. What concerns me is when nobody can explain why the old environment is still needed, or what would allow it to be retired.
In my recent work on information access, hosting transitions and platform-consolidation assessments, three questions have become particularly useful: Can people still do their work? Who supports them after the change? What are we still paying for?
These belong in the original business case, not on a list of loose ends after go live.
Business Capability: Preserving What People Need To Do
A recent mailbox-capacity alert brought the first question into focus. I updated the archive settings, then explained where older messages would remain accessible and that the change had not deleted them.
The configuration was only part of the work. The person using the mailbox also needed to know where to find their correspondence.
That same requirement matters in larger transitions. A finance team may need an old record to investigate an invoice. An operations manager may need to confirm an earlier customer commitment. Before retiring a system, you need to understand those needs well enough to preserve them.
That doesn’t automatically justify keeping the entire platform.
Start with the business owner. What information is needed, who needs access and what task does it support? Work with the appropriate records and legal stakeholders to establish retention and disposal requirements. Then decide which arrangement meets them.
The acceptance test should reflect actual work. Ask an authorized employee to retrieve a record, interpret it and complete the relevant task. Check that the restrictions on access still work, too.
Moving the information is a technical result. Making sure people can use it is a business result. Both matter.
Operating Ownership: Making The Handover Clear
During a Microsoft 365 consolidation assessment, device-management components, identity applications and conditional access policies required further scoping beyond standard migration objects.
Those details affect more than the migration plan. They affect how the environment will be supported afterward.
Who will administer access? Who handles a device that no longer meets policy? Who resolves an exception involving both the new environment and a retained service?
These responsibilities should be settled before the handover. Naming a provider in a project document isn’t enough. The agreement needs to explain what that provider owns, what remains with the internal team and how problems crossing those boundaries will be resolved.
Employees shouldn’t have to work out which supplier to call while trying to finish their jobs.
Business owners need to participate as well. They can confirm whether the resulting service supports the workflow and whether any remaining limitations are acceptable.
For a legacy service that stays, I recommend recording its purpose, owner, support arrangement and review date. There should also be a clear condition for reconsidering it. “We still need it” is a starting point for a discussion, not a complete operating plan.
A CIO needs to bring these responsibilities together so that the handover works in practice.
Financial Closure: Accounting For What Remains
In ongoing hosting-transition reviews, I’ve been examining which services can be discontinued and what limited support may still be necessary for a legacy system used primarily for historical reference. Scope, contractual commitments, responsibilities and pricing all need to be understood.
This work is less visible than launching a replacement, but it matters to the investment decision.
A migration milestone doesn’t tell finance when the previous charges will stop. A smaller supplier invoice doesn’t necessarily mean the work disappeared. Some responsibilities may have moved to internal employees or another provider.
The comparison needs to cover the full arrangement: new recurring costs, retained services, transition expenditure, overlap and the capacity required to support it.
Be precise about the benefit. Removing a recurring charge, postponing expenditure and transferring work are different decisions. Forecast savings should remain forecasts until the changes are implemented and the results can be checked.
There’s also no reason to force every worthwhile investment into an immediate savings story. Better resilience or a necessary business capability may justify the expenditure. Make that case directly.
Where overlap is needed, explain what it protects and what will allow it to end. Give someone responsibility for reviewing it.
That makes the continuing cost an explicit business decision rather than something everyone assumes the project team will eventually resolve.
Separating Go Live From Business Completion
I recommend treating technical go live and business completion as distinct approval points.
Go live confirms that the replacement is ready to operate against agreed technical criteria. The completion review confirms that the required workflows have been accepted, support responsibilities are understood and continuing commitments have been reconciled.
A one-page decision record can organize that review around the three questions: business capability, operating ownership and financial closure. Include the supporting evidence, unresolved exceptions, accountable owners and the next decision dates.
The answer may be that a legacy service needs to remain. That can be a sound outcome when its purpose and obligations are clear. What you should avoid is retiring something necessary to make a project look finished, or keeping it indefinitely because no one owns the decision.
Modernization gives leaders an opportunity to reconsider what the business needs, not simply replace what it already has.
For a CIO, the final question is not just whether the new platform works. It is whether the business can safely let go of what it was meant to replace.
Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?
