Part of the Finance systems at end of life series.
A vendor support deadline means one thing precisely: after that date, the vendor will no longer issue patches, regulatory updates, or fixes for that product version. It does not mandate migration. The deadline sets a date; it does not set a direction. Yet most groups treat the two as synonymous and skip a genuine cost comparison of the four realistic options.
What does an end-of-support deadline actually oblige a group to do?
Nothing, in a strict legal sense. The obligation runs the other way: once support ends, the vendor is no longer obliged to maintain the software. What changes for the group is the risk profile, not the immediate legal requirement to act. The CFO's job is to price that risk honestly against the three alternatives to migration - and then choose deliberately rather than by default.
Option one: Stay put and accept the risk - what are you actually accepting?
Running an unsupported system is a business decision, not an accounting irregularity in itself - but it carries three specific exposures that must be owned explicitly.
Security patching. The vendor will not issue patches for newly discovered vulnerabilities. The group's IT team either back-ports fixes manually (resource-intensive and often impractical for complex finance platforms) or accepts an expanding attack surface. For a system that touches treasury, payroll, or intercompany settlement, the exposure is material.
Regulatory and tax updates. Statutory reporting requirements, tax-rate tables, electronic filing formats, and jurisdiction-specific rules change continuously. On an unsupported system, the group is responsible for applying those changes manually or through bespoke development. In a multi-jurisdiction group, the cumulative maintenance burden can exceed the cost of a structured upgrade within a relatively short horizon - though the precise crossover depends on the group's footprint.
The auditor's view. External auditors assess the control environment. An unsupported finance system is a known audit risk item. It will typically appear in the management letter and may affect the auditor's assessment of IT general controls, which feeds directly into the opinion on financial statement reliability. Groups should get a clear, written steer from their auditor before committing to this path for more than one reporting cycle.
The cost of deferring. Staying put is not free - it is a decision to pay the cost of risk rather than the cost of change. That trade-off is rational only if the group has priced it explicitly. If the system is genuinely stable, the regulatory surface is narrow, and a planned migration is eighteen to twenty-four months away with a defined project already funded, staying put can be the right call. If none of those conditions hold, it is simply avoidance.
Option two: Vendor extended maintenance - what does it actually buy you?
Where a vendor offers extended maintenance or extended support programmes, these typically provide a defined, time-limited continuation of patching and critical updates beyond the standard support deadline, at a higher licence or maintenance fee. The key questions to resolve before accepting this option are: does the extended programme include regulatory and tax updates for your jurisdictions, or only security patches? Is there a ceiling on how long it runs? And does taking it affect your negotiating position on a future upgrade?
Extended maintenance is a legitimate bridge where the group has a credible, funded migration plan and needs twelve to thirty-six months of runway. It is not a long-term operating model - the vendor is signalling, by offering it at premium pricing, that the direction of travel is replacement.
Option three: Third-party support - what is the category and what does it actually provide?
Third-party support is a market category in which independent firms - not the original vendor - take on the maintenance obligation for an agreed scope of work, typically at a lower annual fee than the vendor's own maintenance rate. The provider issues patches, supports regulatory and tax updates, and handles break-fix for the supported version.
What third-party support does not provide is new functionality, version upgrades, or access to the vendor's development roadmap. A group on third-party support is, by definition, running a frozen version of the application. That is the trade-off: lower ongoing cost in exchange for no forward development. For a system that is genuinely stable and fit for purpose in its current state - where the group's real gap is in adjacent areas rather than the core platform - this can be a rational medium-term position.
The CFO accepting this option is accepting: that the system will not evolve; that the burden of proving regulatory compliance rests with the group and its chosen provider rather than the original vendor; and that the auditor will need a clear explanation of the control framework around a non-vendor-supported system. Get that conversation on the record before signing the third-party contract.
Option four: Migrate - what are you actually committing to?
Migration is the option that receives the most attention and the least rigorous pre-commitment scrutiny. A group that moves straight to a replacement platform without pricing the other three options has not made a business decision - it has made a technology decision dressed as a business one.
What migration obliges the group to accept: a capital and resource commitment that is typically larger than the initial estimate; disruption to the close, consolidation, and statutory reporting cycle during cutover; a period of parallel running that compresses the finance team; and the risk that the new platform's configuration does not replicate the institutional knowledge embedded in the old one.
None of that argues against migration - the level-5 frontier of AI-embedded finance requires modern, integration-capable platforms. The argument is that migration should be chosen because it is the right answer, not because the deadline made it feel like the only one. A group that has genuinely priced options one through three and concluded that migration delivers the best risk-adjusted outcome is in a far stronger position to build the business case and defend it at board level.
The decision the CFO actually needs to make
Set the options side by side in a single page: the cost of staying put (risk-adjusted, not nominal), the cost of extended maintenance, the cost and scope of third-party support, and the full cost of migration including internal resource. The Finance Value Score's business case output is designed to express exactly this kind of gap in pounds - the value at stake from operating below the level-5 frontier - which gives the board a number rather than a direction. The deadline is the prompt. The decision is yours to make with evidence.
Common questions
Does an end-of-support deadline legally require a group to migrate?
No. An end-of-support deadline removes the vendor's obligation to maintain the product - it does not create a legal obligation for the customer to replace it. The group must then decide which of the four options best fits its risk appetite, regulatory surface, and capital position. Migration is one option, not the automatic consequence of the deadline.
What is the auditor's typical concern with an unsupported finance system?
Auditors assess IT general controls as part of their review of the financial reporting environment. An unsupported system - one receiving no vendor patches or regulatory updates - is a known control weakness that will typically appear in the management letter and may affect the auditor's assessment of the reliability of financial statement outputs. Groups should obtain a written position from their auditor before committing to running an unsupported system beyond one reporting cycle.
What does third-party support actually cover, and what does it exclude?
Third-party support providers maintain a frozen version of the application - they issue patches, handle break-fix work, and support regulatory and tax updates within an agreed scope. They do not provide new functionality, version upgrades, or access to the original vendor's development roadmap. A group on third-party support is trading lower cost for no forward development; that trade-off is rational only where the platform is genuinely stable and fit for current purpose.
Is vendor extended maintenance a long-term solution?
Vendor extended maintenance is a bridge, not a destination. It typically provides a time-limited continuation of patching and critical updates at a premium fee, and vendors offer it as a signal that the platform's development direction is replacement. It is a legitimate option where a group has a funded migration plan and needs a defined runway - it is not a viable long-term operating model.
What is the main risk of defaulting to migration without pricing the alternatives?
A group that moves straight to migration without costing the other three options has made a technology decision rather than a business one. Migration carries a capital and resource commitment that typically exceeds initial estimates and disrupts close and consolidation cycles during cutover. The business case for migration is strongest when it has been chosen against quantified alternatives - not simply because the deadline made it feel obligatory.