You replaced your ERP three years ago and the old application is still running on a box in the corner of the server room. Nobody uses it every day, nobody wants to touch it, but nobody dares switch it off either. That's exactly what "sunsetting" means — and exactly why almost nobody does it properly.
We see this pattern in every second company we're invited into. The new system works, processes have shifted, people no longer click the old icon on their desktop. And yet the old program keeps running. Because someone drops in once a quarter to check a historical invoice. Because the database "has some data that might be useful". Because the licence is paid up until the end of the year. Because — and this is by far the most common reason — nobody has ever written down when and how to finally turn it off.
The result is always the same. The company pays every month for a server, licences, database updates, backups and admin time on something that in practice two people touch, every few weeks. On top of that the risk grows: the system hasn't been patched for two years, runs on Windows Server 2012, on a Firebird database nobody in the company understands any more.
Why old systems never die
Behind every "we can't switch it off" is one specific, narrow reason. And almost always it can be solved for a fraction of the cost of running the system for another year.
Most often it's one of four things: historical invoices and documents that accounting needs to be able to read for five years back. A customer or supplier record with notes nobody has migrated. A management report someone runs once a quarter and which "only looks right in there". Or — the most frustrating — one single feature the new system simply doesn't have, so two people log into the old one out of habit.
None of those reasons justifies keeping a live server with a full application install. Each one can be handled separately. But until somebody writes them down on paper, together they form a wall the sunset project never gets past.
What "sunset" actually means
Sunset isn't a single day when someone clicks "shutdown" on the server. It's a 3–6 month project in which you disarm, one by one, each reason the system is still running. At the end, when there are none left, you actually do click shutdown.
A concrete example. One of our clients — a 28-person electrical wholesaler, after their 2019 migration from a bespoke Delphi + Firebird system to Comarch Optima — kept the old application running for another five years. Two people in accounting logged in on average once a week to fetch historical invoices from 2011–2018. The whole infrastructure — a hosted server, licences, backup, one admin-hour a month — was costing the company around PLN 1,600 a month. Over a year, roughly PLN 19,000 for a system nobody was actually using to run the business.
The sunset took four months. We exported 47,000 invoices to PDF with an Excel index, moved the customer notes into a text field in Optima, and rebuilt one report in Power BI. The server went off on a Friday evening. On the Monday, nobody noticed. The company got back one hour of IT admin time a week and about 4,000 euros a year in infrastructure.
The sunset plan — step by step
Sunsetting has a simple structure that's worth sticking to:
- Usage inventory. For 2–4 weeks you run a simple log: who logged into the old system, when, and for what. Without that you're guessing. Usually it turns out 2–3 people use it, for 3–4 specific things.
- List of what must be preserved. Write down exactly what has to remain accessible after shutdown — invoices, contracts, notes, reports. Precisely: "sales invoices 2015–2019 in PDF format, indexed by tax ID and invoice number". Not "sales history".
- Archive format. Choose the format the data will live in from now on. Usually PDF plus an Excel index, plus a CSV dump of the database. It's almost never worth standing up a second, "read-only" install of the same system — that only kicks the problem down the road.
- Migrate the things that must keep working. The one un-migrated feature or the one report gets moved into the new system — Optima, Power BI, wherever. That's usually 5–15 person-days of work.
- Parallel period. The old system keeps running for another 4–6 weeks, but write-locked. Users learn that a 2015 invoice lives in the PDF archive now, not in the application.
- Shutdown and verification. You switch the server off, but you don't delete the database backup for another 12 months. In case something surfaces — there's something to restore from.
The plan isn't complicated. What's complicated is the decision to start it in the first place.
Traps worth watching out for
Sunset has three classic traps that everyone hits the first time.
"We'll do it ourselves when there's a moment." That moment never comes. Sunset needs a budget, a deadline and one accountable person — otherwise the old system just keeps running for another year.
Export without an index. You dump 30,000 PDFs into a folder with no structure. A year later, when accounting is looking for one specific invoice from 2016, the archive turns out to be useless. An index (a CSV with tax ID, date, amount, invoice number and file path) is a mandatory part of the migration. Without it, the archive is a rubbish tip.
Shutdown before communication. Someone in accounting logs in once a quarter, at month-end. If you pick that Wednesday to hit shutdown, you'll get a Tuesday phone call saying "the data has suddenly vanished". Communication with users — by name, with a date, with instructions on where to find the data now — has to go out a week in advance.
When it's not the moment yet
Not every old system is ready to be retired this year. Three situations where it's worth waiting:
- The new system isn't stable yet — the risk of falling back to the old one is real. Only start sunset once the new environment has run cleanly for 6+ months.
- The old database holds data you can't cleanly reproduce in the new system (e.g. complex cost calculations). First close that gap in the new one, then retire the old one.
- The financial year is ending and accounting wants a "safe" version of access to history until close. Plan the sunset for January–February of the following year.
Outside those three — if a system has been running "just in case" into its second year, it's time to switch it off. Every extra month is cost without value.
What to do this week
Three things you can do straight away, without a budget and without a board decision.
First, write out a list of old applications still running "just in case". Name, which server, who last logged in this year, roughly what it costs to keep running. Usually it comes to 2–4 items, and the total at the bottom of the page is larger than anyone thought.
Second, turn on usage logging on the oldest item on that list. In a month you'll know precisely who is going in and why.
Third, add "retire system X" to next year's IT plan, with a specific budget and deadline. If you don't plan it, it won't happen by itself.
Retiring legacy systems is one of those things no IT supplier will proactively propose to you, because it directly reduces their revenue. That's why it almost never happens without an internal decision.
An old system won't disappear on its own. Sunset is a project — with a deadline, a budget and one accountable person. Without that, it just runs another year.