Migrating your old business software in Algeria in 2027: WinDev, Access, Excel, Delphi, the move to a web and mobile platform without losing an invoice and without stopping the business.

The inventory takes one to two weeks and needs no code: the list of screens in use and those no longer used, of documents printed every day, every week and every month-end, of the people who enter data and what they do beside it, the notebook, depot 2’s Excel file, the WhatsApp photo of the stock. You also note where the database is, who holds its password, and what the vendor contract says. The extraction is the technical moment: the database is read with the tools of its format, HFSQL, Access, SQL Server, or by screen export if it is locked, and copied in full, twelve years included, into an open database; the extraction script is replayed as often as needed, because the data keeps changing until the switch.

The first module in parallel is usually sales and stock, because that is where the invoices are. For a few weeks, the same operations are entered in both systems, or replayed automatically from the old to the new, and the reconciliation compares every week the totals per month, per customer and per item: a difference is a forgotten rule, not a detail. The switch is made for that module alone, with the old system still available to read; then the method is repeated for purchasing, the till, deliveries. Switching off comes last: the old software goes read-only, an archive is kept, the PC is unplugged, and the vendor contract can be closed.

Two texts every developer knows have said the same thing for twenty-five years. On 6 April 2000, Joel Spolsky wrote that rewriting software from scratch is the worst strategic mistake a company can make, with the example of Netscape, which went almost three years without a release during its rewrite; in 2004, Martin Fowler described the strangler fig, a new system growing around the old one, function by function, until it replaces it. Migrating business software follows that second path. The data layer is carried over in full and becomes the company’s asset: an open database, in its name, copied every night, exportable on request. The rules layer is rewritten, but every rule is replayed on past invoices until the totals match, because the cumulative discount, the rounding and the tolerated negative stock are often in the code and nowhere else.

The web layer first reproduces what users already do, with identical printed documents, then adds the three depots in one database, roles per person and the action log. The mobile layer is what the 2013 software did not have: order taking at the customer’s, the depot stock on the driver’s phone, collection, offline when the network is missing, and the day’s figures on the owner’s phone. The management layer comes last and benefits from the whole history: the dashboard per depot, which we describe in the guide on dashboards and business intelligence, and an AI agent that answers in French or Arabic “which customers dropped by 30 % this year” over twelve years of invoices, which no printed report ever did; we explain where an AI agent pays off in an Algerian company in a separate guide.

The data. 68,000 invoices over twelve years, 3,900 customers, 2,600 items, read from the HFSQL database with the vendor’s tools and copied in full into an open database; the script runs in twenty minutes and can be replayed every night until the switch. The modules. Five, in the order of the invoices: sales and stock, purchasing, till and collections, deliveries on mobile, dashboard; each is only started once the previous one has switched. The parallel run. Four weeks for the first module, during which the old system’s sales are replayed every night into the platform; 36 monthly totals, three years per depot, compared to the dinar, and the two differences found in this example are two rounding rules nobody had written down.

The downtime. Zero days: at no point did an invoice have to wait, because the old software stayed available until every module had been reconciled. What the company gets at the end. The three depots in one database instead of three copies reconciled by e-mail, fourteen users each with a role, sales reps taking orders on their phones, the owner seeing the day’s sales from Marseille, and twelve years of invoices queryable in one sentence. Price and lead time depend on the number of modules, the state of the database and what must be reproduced identically; we give the total price before starting, as in all our guides.

The all-or-nothing weekend is the most common way to go back to the old software for six months: an invoice will not print on Monday, the sales staff reopen the old system, and the platform becomes “the thing we will try later”. Data cleaned up by hand, that is carried over by half, condemns the platform to live beside the old one, kept open “to look things up”; eighteen months later it is still there. Hidden rules are only discovered through reconciliation; that is why it is done in figures and weekly, not as a re-reading of screens.

The report nobody mentioned is usually the statement printed for the owner or the accountant; ask for it during the inventory, by looking at what comes out of the printer at a month-end. The vendor who keeps the database is dealt with before any commitment: can the database be read with its own tools, otherwise by screen export, and does the contract allow copying it; we describe the extreme case in the guide on the app stuck with a developer who disappeared. Habits, finally: keyboard entry that takes twice as long is a failure, whatever the quality of the rest; screens are drawn with the people who will use them, and the pilot runs on one depot before the others.

We keep all the data and its numbering, the substance of the rules as the company practises them, the field order and the shortcuts users care about, the printed documents in the format customers know, and the gestures that work: the invoice in three clicks, the end of day in ten minutes. We rebuild the data format, an open and backed-up database; the form of the rules, written and tested, changeable without calling the developer back; the screens for everything that did not exist, web, mobile, roles, depots; the production of documents, generated and sent by e-mail or WhatsApp; and all the workarounds, the notebook, the Excel file, the stock photo, which disappear because the platform does what they compensated for.

The only line where nothing is kept is the server under the stairs. Hosting is chosen with the company, according to its constraints and its customers, with off-site copies, access by role and a log of who did what; we detail what a platform costs to keep alive, servers, stores and updates, in the guide on the cost of a year of an application.

January: inventory and extraction. The screens, the reports, the people; the database read and copied in full; a first reconciliation of totals to know whether the database is sound. February to April: the first module in parallel. Sales and stock entered in both systems or replayed every night, totals compared every week, forgotten rules found one by one; Ramadan falls in this period, and nothing is switched during it. May: the switch of module 1. Final reconciliation, old software read-only for this module, a way back kept for a month.

June to September: modules 2 and 3. Purchasing, till and collections, then deliveries on the phones of sales reps and drivers, with the same method and shorter parallel runs, because the data and the habits are already in the platform. October and November: management. Month-end statements reproduced and checked over a full financial year, the dashboard per depot, the AI agent over the history. December: switching off. Read-only, archive kept, PC unplugged, vendor contract closed, and a 2028 financial year that opens in the platform alone.

Should we abandon WinDev, Access or Delphi, or can the existing software be modernised?

Both exist. If the source code is available, the vendor answers and the need is only a new report or a fix, modernising the existing software is reasonable and costs less. If the need is several sites, mobile, remote access, AI over the history, or if the code and the vendor are gone, the web and mobile platform built on the carried-over data is the way. The inventory of moment 01 settles it in writing, with the three options and their total price.

Our vendor will not give us the database. What can we do?

Start with the contract and the format. An HFSQL, Access or SQL Server database can usually be read with the tools of its format if you have access to the file, even without the vendor; if it is encrypted or protected by a password the vendor refuses to give, the data is recovered by screen export and from printed statements, more slowly but completely. In every case, the first action is a copy of the database files in the company’s name, before any discussion. The guide on the app stuck with a developer who disappeared describes the procedure asset by asset.

How long does a migration take?

About four to six months for the first module, inventory and extraction included, on classic business software; the following modules go faster because the data and the habits are already in the platform. A company with three depots and five modules fits in the year, as in the calendar above. We detail real lead times in the guide on how long it takes to develop a platform.

Can we keep Excel during the migration?

Yes, and it is often necessary: depot 2’s or the sales rep’s Excel files are data sources like any other, read and carried over by script. What disappears after the switch are the workarounds, the file that compensated for what the software did not do; Excel exports from the platform remain available at any time for the accountant and the owner.

Is it better to migrate to an off-the-shelf ERP like Odoo than to a custom platform?

It depends on the distance between your rules and the product’s. An off-the-shelf ERP suits a company that accepts working the way the product intends and has no particular mobile field work; the custom platform suits a company whose rules, documents and field work are its own and which wants to keep them. In both cases the data is carried over the same way. We compare the two paths in the guide Odoo or custom ERP.

If we only move the PCs to Windows 11, is the problem solved?

The security problem of the workstation, yes, if the PC accepts Windows 11, which Microsoft’s criteria, TPM 2.0 chip and recent processor, do not guarantee for old machines. The rest does not change: the software stays single-user or on a local network, without mobile, without remote access, with a database only the vendor knows how to open. Changing PCs is an expense; migrating the data to a platform is an investment, and both can be done in the same year, in this order: copy of the database, then migration, then renewal of the workstations.