The letter says your system dies in March. Five patterns to recognize before you let someone else set your clock.
I run buyer-side advisory for governments, which means I am usually in the room a few weeks after the letter arrives. This is what that letter does to a decision.
Here is how a large number of government software purchases actually begin.
A letter arrives. Your vendor is discontinuing support for the system you have been running for fifteen years. The date is firm. It is usually somewhere between nine and eighteen months out, close enough to frighten a finance director and far enough away that it sounds reasonable.
The second paragraph of that letter has good news. There is a new product. The migration path is already mapped. Sign here.
I have been doing this for twenty years and I still find that sequence remarkable, because it is not a notice. It is a sale with a deadline attached, and the deadline was set by the person making the sale.
Once that letter lands, the agency’s real choice is gone. They stop asking what they need and start asking how fast they can move. Every decision after that gets made under a clock somebody else wound.
The ERP playbook on Start at Zero with AV walks that same clock: vendor pressure, a migration date, and why the work has to happen before anyone rushes to market.
Here are five patterns worth recognizing before you let someone else set your timeline.
Pattern 1: The Deadline Is More Negotiable Than You Think
The part almost nobody knows: there is an entire industry of third-party firms that provide extended support for major enterprise platforms after the original vendor walks away. Not from the vendor. Independent. For a fee, they keep your system patched, supported, and running while you decide what you actually want.
This market exists because end-of-support is a commercial event, not a physics event. The original vendor stops shipping patches and answering tickets. The software does not vanish. Third-party maintainers have been doing this for decades on mainframes, databases, and ERP stacks. They are not free, and they are not a strategy for forever. They buy time.
That is not a permanent answer and I would not recommend living there. But it converts a nine-month panic into a two-year decision, and those are completely different projects. One of them produces a considered selection. The other produces whatever you could sign in time.
When the letter arrives, the first call should not be to the vendor who sent it. It should be to someone who can tell you what your real options are for staying where you are.
The pattern: A vendor’s end-of-support date is the end of their obligation, not the end of your system’s life.
Pattern 2: Arbitrary Go-Live Dates Are the Same Trick, Later
Manufactured urgency does not stop once you sign. It just changes shape.
Now it is a go-live date. Someone will tell you the platform implements in six months, and that number is not a lie exactly. It is true for the vanilla configuration, on a clean organization, with dedicated staff and no legacy data problems. It has almost nothing to do with you.
Then the date becomes the organizing principle of the entire program. Testing gets compressed because the date is fixed. Data cleanup gets deferred because the date is fixed. Change management gets dropped entirely, because it is the only workstream with no hard dependency and the date is fixed.
Projects go sideways because they were aimed at a target that made no sense on day one. Every organization is different, and the honest implementation timeline is a function of your data, your decision speed, and how many of your people you can actually free up.
The pattern: If nobody looked at your organization before picking the date, the date is not a plan.
A date picked before anyone looked at you is also not a way to discover whether you should replace the system at all. That sequence is in Going to Market Is a Decision, Not a Diagnostic. If the letter is an Ellucian Banner notice and the path on offer is a move to SaaS, start with the Phase Zero checklist: needs, data, process, and people, before that clock runs the program.
Pattern 3: It Is Never the Technology
I use the Birmingham City Council Oracle program in the book as an example, and the first thing I say about it is that it did not happen because the product was Oracle. Horror stories exist across every platform on the market. Birmingham started at a $19 million budget and ended closer to $216 million. That gap is not a software logo problem.
The early warning sign is almost always the same, and it is on the buyer’s side. The organization does not grasp the volume of work that is about to land on it. When you sign the contract, you are agreeing to do a great deal of homework: clean the data, decide how the business processes should actually change, make hundreds of decisions quickly, and free up the people who know how things work.
Then the implementation starts and everyone’s day job continues unchanged. Decisions queue up. Data cleanup slips. Eighteen months later, eighty percent of the budget is spent.
Part of what makes this hard to see coming is that the vendor’s incentive points the other way. They are motivated to reach their definition of go-live, invoice it, and move to the next engagement. If they checked their boxes and you did not do yours, the contract may well say they were right.
The pattern: Failure usually looks like a technology problem in month eighteen and looked like a staffing decision in month one.
Pattern 4: Once You Are in Trouble, Every Option Is Bad
We get brought in to do health checks and rescues constantly. The most recent was a large West Coast agency, eighteen months in, with the configuration built and essentially nothing else. Data nowhere near ingested. Testing not started. Change management never undertaken.
From a pure software standpoint the work was done. It was not going to function for the agency.
There are exactly three options at that point. Abandon it and stay on the legacy system. Re-baseline the program, go do what should have been done eighteen months earlier, and replan, usually with a budget conversation attached. Or keep the platform and replace the system integrator.
All three are bad. Which one you pick has less to do with analysis than with your financial and political capacity to absorb the consequences. That agency chose to re-baseline and do it properly the second time, which I think was right, and it still cost them.
The reason to understand this now, while nothing is wrong, is that the cheapest moment to prevent it is before the contract is signed.
The pattern: There is no good exit from a failing implementation, only a least-bad one, and the choice is political more than technical.
Pattern 5: The Reason to Modernize That Nobody Puts in the Business Case
End-of-support drives most of these projects, and new leadership who has used better systems elsewhere drives many of the rest. Both are legitimate. But there is a third reason that almost never makes the memo to council, and it should.
You are competing for talent. The people you are trying to hire into finance, procurement, and IT have expectations about the tools they will use. A system can work perfectly well and still cost you candidates. Nobody builds a career plan around green screens, and the person you most want to hire has other options.
The related point is about what AI actually requires. Most organizations are buying a sliver of it, usually a chatbot on a website, and calling it an AI strategy. The chat interface is the retail end of this technology. What it can actually do is run workflows, with humans approving at the end of the loop, and that requires clean data, real governance, and processes that were documented before anyone automated them.
None of that is technical work. It is discipline, from every analyst and project manager who touches a record. Which means the modernization argument and the AI argument are the same argument, and both of them are really arguments about your operating floor.
The pattern: The case for modernizing is about the people you want to hire and the data you will need, not just the system that is aging.
Once that operating floor is in a contract, the RFP can still assume one AI rulebook that no longer exists. That problem is separate, and it is in Your RFP assumed one AI rulebook. You no longer have one.
The Bottom Line
- Check who set the deadline. Third-party extended support exists for most major platforms and can turn a nine-month panic into a two-year decision.
- A go-live date picked before anyone looked at you is not a plan. Published implementation timelines describe a vanilla configuration on a clean organization.
- It is never the product. The early warning sign is a buyer who has not grasped the work landing on their own staff.
- Every rescue option is bad. Abandon, re-baseline, or swap the integrator. Understand this while nothing is wrong.
- Talent and data quality belong in the business case. They are the reasons that survive contact with the next platform generation.
The through line is control. If you wait until something breaks, you do not get to start from zero. You get to react, on someone else’s schedule, to a problem defined by whoever sent the letter.
Start before you have to, and the whole thing becomes a different exercise.
If the letter is already on your desk, name the real options before the date in it becomes the plan. Write to us. A sentence is enough. If we cannot help, we will say so. The buyer-side work is under services.
AV
Subscribe to Start at Zero for the weekly essay. Free.
Watch: Start at Zero with AV
Read: Start at Zero, the book
Consulting: averoadvisors.com