Algeria AgencyWeb & software
Replacing a system that still works
Four reasons justify replacing an old application. Outside those four, keeping it is almost always the right call — and nobody has an interest in telling you so.
There is a conversation almost nobody has an interest in having honestly with you, and it is this one: should you replace the software you have been using for twelve years? The new vendor is paid if you say yes. The integrator is paid if you say yes. We are paid if you say yes.
So let us start with the answer that costs us money. In roughly half the enquiries we get on this subject, the right advice is to do nothing. An old application that does the job, that somebody knows how to operate, and whose data comes out, is not a business problem. It is a written-down asset.
This article gives the four conditions that genuinely do justify replacement, and gives them precisely enough that you can check them yourself, without us. Three can be established in an afternoon. The fourth requires a test few companies have run.
It then describes what a migration actually runs into when it is justified — the encoding, the paper, the rules nobody wrote down, the person who leaves — because that is where these projects fail, and never in the development of the new software.
"Old" is not a diagnosis
A system’s age says nothing about its value. An application written in 2009 that issues your invoices correctly issues your invoices correctly, and the fact that it looks like 2009 costs nobody anything — except the person looking at it hoping to sell its replacement.
The word that stands in for an argument, in nearly every quote our clients show us, is "obsolete". It is an empty word. It names no verifiable property of the system: it names the impression the system gives. Ask what it means precisely and the conversation immediately becomes more useful.
Four conditions, by contrast, are verifiable, and they are the only ones that justify the spend. The software no longer receives security patches. One person alone knows how to run it. It prevents you from doing something you have to do now. Or its data does not come out.
Those four are not opinions. Each can be established, and three can be established without outside help. If none applies to you, the right decision is to keep the system and put the money towards something that is genuinely missing.
The rest of this article assumes at least one applies. If that is not your case you can stop here, and that is a result: you have just saved a budget somebody was preparing to have you spend.
For many companies the central system is a spreadsheet
When people say "legacy system", the image that comes to mind is old software on a server. In the companies we see, the reality is more often a workbook.
It started as a convenience — a table to track orders, just for now. Then somebody added a tab, then a formula, then a colour that means something only one person knows. Today it runs the company, it lives on one machine, and it has somebody’s name in its filename.
We do not know what proportion of Algerian companies are in this position, and we are not going to invent it: nobody publishes that figure, neither the ONS nor any sector survey we have been able to verify. What we can report is what we see among our own clients, and that is not a statistic.
What does matter is that such a workbook meets the four conditions more often than real software does. One person knows how it works. It has never received a single patch. It prevents nearly everything — simultaneous work, history, input validation. And its data comes out badly, because a spreadsheet has no imposed structure.
A workbook that has become critical is therefore a legacy system in full, and it is handled with the same precautions as an application: exit audit, history migration, parallel running. Treating it as "just an Excel file" is the most common way to lose ten years of data.
The only one of the four conditions that carries a date
Of the four conditions, only one comes with a public calendar: the end of security patches. The others degrade slowly; this one has a date, it is written by the vendor, and it is not negotiable.
Microsoft’s fixed lifecycle policy is the most useful example, because most old business software runs on a Windows Server, and the server’s end date effectively becomes the end date of the software it carries.
The chart alongside gives, for the three editions still in service, the number of months of patches remaining. The 2016 edition is at five months. That is not a distant warning: it is a quarter and a half, and a serious migration project needs more than that.
What "end of patches" means deserves saying precisely, because the phrase reassures wrongly. The server does not stop. It carries on working exactly as it did the day before. What changes is that from that date, every flaw discovered stays open forever, and those flaws are published.
It is the only one of the four conditions that imposes its calendar on yours. The other three let you choose the moment; this one chooses it for you, and ignoring it turns a planned project into an emergency response, which costs more and is done worse.
Microsoft fixed lifecycle policy, consulted 2026
The person who knows, and what leaves with them
In many companies the system does not rest on documentation but on an employee. They know what order to start things in, what to do when that particular error appears, and why you never enter an order on the last day of the month.
That knowledge is written down nowhere, and not writing it down was not laziness: nobody knows they hold it. It reveals itself the day that person is absent, and it is measured only then, in hours of stoppage.
The risk is real but badly handled, because it is treated as an IT risk when it is a people risk. Replacing the software does not automatically remove it: a new system can rebuild exactly the same dependency in eighteen months if nobody writes anything down.
What removes the risk is the writing, and the replacement is only the occasion for it. A well-run migration spends a serious share of its time following that person, asking why they do what they do, and turning their answers into explicit rules.
It is also why a migration cannot happen while people carry on working normally. If you cannot free up the person who knows, the migration will produce a system that does what the specification described, rather than what the company does.
Data before code: the only test that counts
The fourth condition is the one almost nobody checks before signing, and the only one that can stop the project dead. Does your data come out?
The question is not "does the software have an export function". Many do, and it exports the screen on display rather than the database. What counts is getting the whole of it out: customers, items, the complete movement history, with the links between them, in a format another program can read.
The test is run before any quote, and it is run for real. We ask for a complete extraction on the real data at the very start, every time, because its result changes the nature of the project. A readable database gives an ordinary migration. A closed one gives a project three times longer, or no project at all.
It is also the test that surfaces the nasty ones early, while they still cost nothing: fields filled in at random because they had stopped being used, duplicates the software was hiding, dates in American format across three specific years. All of it is repairable before migrating, and far less so afterwards.
A supplier who gives you a firm price for a migration without having seen your data has not given you a price. They have given you a hypothesis, and you will carry the overrun alone.
Arabic and French in the same file
Now the difficulty that foreign articles on this subject never mention, and which here is the leading cause of a failed migration.
Some of the data entered into the software installed here through the 2000s and 2010s was entered in Arabic, on systems built when universal character encoding was not yet the norm. Some was entered as Arabic transliterated into Latin characters, by an operator in a hurry or by a form that accepted nothing else. Some is in French.
On extraction this does not produce a clean error, which would be preferable. It produces a mixture: some names come out correctly, others come out as unreadable character sequences, and nothing flags the difference. The file looks fine when you open it and read the first twenty rows.
We cannot tell you what proportion of a typical Algerian customer file is affected, because that figure does not exist — it depends on the original software, the year of installation, and each company’s data-entry habits. What we can say is that it is never zero, and that it has to be measured on your data rather than assumed.
The repair is a job in itself: identify the encodings present, convert them, and have a sample read back by somebody who reads Arabic and knows your customers. That last part cannot be automated, and a migration quote that does not budget those hours is planning to discover them mid-project.
What the software does is not what the company does
There is always a gap between the procedure as described and the procedure as practised, and that gap is the real content of the project.
The examples rhyme from one company to the next. That customer pays at sixty days but is entered at thirty because otherwise the software blocks the order. That discount is not entered at all, it is applied by hand on the invoice. That "internal reference" field has actually held the salesperson’s name since 2017.
None of these rules is written down. All of them are indispensable. And none will appear in a specification drafted in a meeting room, because the people who apply them do not experience them as rules: they experience them as the normal way to work.
The only way to recover them is to watch people work, over several days, asking questions about what looks trivial. It is time many suppliers do not bill because it is hard to justify on a quote, and it is exactly the time that decides whether the new system gets used or worked around.
A system that does not know these exceptions is not rejected loudly. It is worked around: a side spreadsheet appears to hold what the software will not accept, and the company ends up with two systems instead of one.
Paper is not a leftover, it is the register
In many Algerian companies, paper is not what remains from before computing. It is the record that carries authority, and it holds information that is in no software.
The delivery book signed by the customer, the stock-intake register kept by the storeman, the folder of order slips annotated by hand: these settle disputes. When the software and the book disagree, the book is believed, and there is a reason for that — it carries a signature.
A migration that ignores this layer replaces a complete system with a partial one. Teams notice within weeks, and they do the only reasonable thing: they keep the paper. The company has then paid for new software and kept the old workload.
Here too we have no national figure to cite on how many companies this affects, and we would rather say so than produce an estimate whose real source is our own impression. The question to ask inside your company is simple and can be answered in a day: in a dispute with a customer, which document do you produce?
If the answer is a piece of paper, then that paper is part of the system to be migrated, and what becomes of it has to be decided explicitly — digitised, replaced by an electronic signature, or kept as it is alongside. Not deciding is deciding to keep it.
The replacement will be read on a phone
The system you are replacing was designed for a fixed workstation, in an office, on a wide screen. Its replacement will be looked at somewhere else, and that changes what to ask of it.
ARPCE’s internet market observatory records some 59.10 million internet subscriptions in Algeria for the second quarter of 2025, of which 88.71% are mobile and 11.29% fixed. That report does not describe leisure use alone: it is also how your storeman, your salesperson on the road and your manager consult what the system holds.
The consequence is not that you need a mobile app. It is that the screens actually used day to day — checking stock, finding a customer, confirming a delivery — have to work on a phone, while heavy data entry can stay at the desk.
It is also a migration argument in its own right, and often the strongest of the four conditions under the heading of "it prevents you from doing something you have to do". Software installed on a single workstation cannot be consulted from a warehouse, and no update will change that.
Finally, the connection here is intermittent rather than absent. A system that demands the network to display information it already holds will be judged broken by its users, even when it is working exactly as designed.
- Mobile subscriptions88.71%
- Fixed subscriptions11.29%
ARPCE, internet market observatory, second quarter of 2025
Why the single-weekend switch fails
The scenario is always the same and it is always proposed for good reasons: stop the old system on Friday evening, migrate over the weekend, start the new one on Monday. Shorter, cheaper on paper, and it avoids running two systems.
What that plan assumes is that everything that could go wrong has already been found. But the only thing that genuinely surfaces discrepancies is use: real users, on real cases, comparing two results. A weekend does not contain that.
The failure mode is not the one people imagine either. It is almost never a clean breakdown, which would be manageable — you would roll back. It is a silent divergence: a stock total off by a few units, a discount applied twice, a customer balance that no longer matches. It is noticed weeks later, once the two systems have drifted apart and there is no way back.
Parallel running is the answer, and its cost is real: for a few weeks, some data is entered twice. That is the price of the only thing that genuinely protects you, which is being able to compare the two systems’ figures day after day until they agree.
We refuse single-weekend switches, and we say so before the quote rather than after. This is not a matter of principle: it is the one risk in this trade that cannot be recovered from once it has happened.
Six questions for whoever is proposing a migration
Here is what to ask, and what the answers tell you. They work on us as well as on anybody else, which is the point of writing them down here.
Have you extracted my data before giving me this price? If not, the price is a hypothesis. And what happens if the extraction turns out incomplete — who pays for the extra work? That answer belongs in the contract, not in the conversation.
How many days have you budgeted to observe my teams working? A quote without those days contains the assumption that the specification is complete, which never happens. And: how do you verify the encoding of Arabic data? A vague answer here forecasts unreadable names in production.
How long will the two systems run together? Any answer under a few weeks deserves a precise justification. Finally: what becomes of the old system once it is stopped? The right answer contains the word "archive" and describes a format you will be able to read without the original software.
A seventh question applies to us too: under what conditions would you tell me not to do this project? A supplier with no answer to that has no criterion, and a supplier without a criterion will always say yes.
What we do with this subject, and what we refuse
Our work on this subject always begins with the same act, and it is not development: we get your data out. In full, on your real files, and we show you what is missing. Until that is done we give no firm price, because we would not know what we were selling.
We refuse three things, and they cost us projects. We do not do single-weekend switches, not when asked, not with a waiver. We do not price a migration whose data has not been extracted. And we do not take a project where the people who use the system cannot be freed up to talk to us, because we would build the wrong software with your money.
There is also a part of this work you can do without us, and it has the best cost-to-result ratio of anything here: work through the four conditions. Three can be checked in an afternoon with no technical skill — your operating system’s end-of-support date is published on the vendor’s site, the number of people who can run it can be counted, and what it stops you doing you already know.
We promise no figure for what the migration will gain you. The gains depend on what your teams do with the time freed up, which is not ours to control, and any agency quoting you a productivity percentage on this kind of project chose it to fit on a slide.
Finally, the honest answer is still often no. If your system still receives its patches, if several people know how to use it, if it blocks nothing and its data comes out, keep it. We will tell you so, and it will cost us a project you did not need.
Frequently asked questions
Our software is fifteen years old. Is that too old?
Age is not a criterion. Check the four conditions: security patches, how many people can operate it, whether it blocks a current need, and whether the data comes out. If none applies, fifteen years is not a problem.
What does a migration cost?
Almost entirely on the state of the data, which is why a price given before the extraction has no value. The range between a clean database and a closed one easily runs to three times.
Can we migrate without stopping the business?
Yes, and it is the only way we work. Both systems run in parallel and the old one stops only when nobody is using it.
Our vendor has disappeared. Are we stuck?
Not necessarily. What matters is access to the database, not the source code. Many older databases can be read with standard tools; the real blocker is an encrypted database whose key nobody holds.
Should we migrate everything, or only recent data?
That is a decision to take explicitly and in writing. Migrating ten years of history costs more than three; not migrating it means keeping the old system available for reading, which has a cost too.
How long should the two systems run together?
Until they produce the same figures over a complete period — at minimum one full billing cycle, and longer if your business is seasonal.
Where we come in
Three of the four conditions take an afternoon to check, without us and without spending. If none applies, this project should not be opened this year.
- We start by confirming your data can get out, before anything else.
- We proceed in stages, never as a single weekend switchover.
- We hand back the export in a format readable without the original software.
A system still getting its patches, which more than one person can run, does not get replaced: the honest answer here is often no.
Read next
The cutover: running the old and the new at the same time
Replacing a system does not happen over a weekend. It happens across a period when both run, and that period has to be designed.Taking back a system nobody answers for: what can be recovered, what has to be rebuilt
Your site runs, your software runs, and whoever built them has stopped replying. A great deal of the answer is public and free.After version one: what evolving custom software really costs
Custom software is not delivered, it is put into service. Everything that matters afterwards turns on how you ask for a change.
Let us talk about your project
A free audit, no commitment: we look at your online presence and tell you what is holding it back.