The end-of-support notice from a vendor is the least useful date in a migration plan. The date that decides whether an end-of-support migration worked is your next peak (the day the traffic, the orders and the month-end all arrive together), and almost nobody plans backwards from it.
Vendor deadlines are clustering on the same horizon. Microsoft ends extended support for Windows Server 2016 on January 12, 2027, and SAP's mainstream maintenance for ECC 6.0 runs out at the end of 2027. End of support means the vendor stops shipping security patches and fixes; the software keeps running, just without anyone standing behind it. The internal pitch for replacing it changes every year. The plan rarely does: a cutover weekend, sized against somebody else's calendar.
We rebuilt Sky Sports' live scores platform when Adobe retired Flash and the entire thing ran on Flash. Adobe fixed the deadline; nobody fixed the requirement. The published results are "11M active users supported", "Sub-second latency from stadium to screen" and "Zero downtime during major events", and the Flash deadline tested none of them. The Champions League finals did.
Sky Sports' rollout was sequenced by stake rather than by calendar. Old and new ran in parallel, traffic moved across gradually, and the order was friendlies first, then league fixtures, then the finals. An end-of-support date tells you when the old system stops receiving patches. Only a peak tells you whether the new one is finished. Every business has one and most already know it by name: quarter close, the enrollment window, the first trading day after a price change, Black Friday. Sport just has the honesty to print the fixture list months ahead.
The hard part was that sports traffic is predictable in timing and unpredictable in volume. You know exactly when a match kicks off. You have no idea how many people will watch it. Anything that needed a human awake to scale it was going to fail at the worst available moment, so scaling had to be automatic, and it had to be proven against a real fixture rather than a load test on a quiet Tuesday. A rehearsal is not evidence of anything except that the rehearsal went well.
Forced migrations also pretend to be like-for-like, and they rarely are. Flash didn't work on phones, so Sky Sports fans on mobile couldn't follow live scores at all. Replacing Flash honestly meant building for mobile as well, which is a bigger piece of work than the notice implies. Whatever is killing your platform has usually already changed your users, so a plan that only reproduces the old system lands late and lands behind.
If you are running delivery against one of these dates, put your own peak calendar beside the vendor's before anything else gets scheduled. Start with an honest inventory of what actually depends on the old system, and backups someone has restored rather than merely taken. If the vendor's date lands too close to your peak, paid extended support (Microsoft sells Extended Security Updates for Windows Server 2016) can buy the months needed to move the cutover somewhere quieter. Then change the question you ask the team or partner doing the work. Skip how much load the new system can take. Ask what load it has already carried in production, with the old system still running next to it, and whether anyone has used the rollback rather than documented it. A plan where the first real peak the new platform sees is the one after the old platform is switched off is not a migration plan. It is a bet with a date on it.
Support ending is a date someone else chose. Your peak is the exam.