Manufacturing & production Usage scenario

Step-by-step modernisation of an old factory management software, without stopping production

Auditing an old Access and VB application, migrating its data and replacing it module by module without stopping production, then maintaining it.

Describe your project See the solution

Project overview

This scenario illustrates what we build; it is not a client reference.

This scenario shows how a factory that depends on an Access and VB application written fifteen years ago can replace it piece by piece: an audit to find out what it really does, a data migration, then one module at a time, the old and the new running side by side until the end. A maintenance contract then takes over.

Client challenges & requirements

A flour mill with around fifty employees manages its wheat purchases, production, flour stock and invoices in an Access and Visual Basic application written by a contractor who can no longer be reached. It runs on a single Windows 7 PC in the accountant's office. Nobody has the source code. When the PC crashes, the mill invoices by hand.

Workshop managers cannot consult it: they call the accountant to know the stock. Every time replacing it comes up, the answer is the same: "we do not know everything it does, and we cannot stop the mill to find out".

Main objectives

Know exactly what the current software does: screens, calculation rules, printed reports, tables

Recover the historical data without losing any and verify it with the accountant

Replace the software module by module, with no day of stopped production or invoicing

Make the tool reachable from the workshop and the warehouse, on computer and on phone

Project solution

Everything starts with an audit

We open the Access database, list the tables, forms, queries and reports, then watch each screen in real use with the accountant and a workshop manager. The result is a document stating what the software does, what is still used and what is not.
Next, the data is migrated to PostgreSQL with a replayable script: run it, compare the totals with Access, fix, run again, until the figures are identical. Then the modernisation proceeds in steps, in order of least risk: first stock consultation (read-only, in Laravel, reachable from a phone), then wheat receipts and flour dispatches, then production, and invoicing last. At each step, the old software stays usable until the team validates the new module.
Once everything is over, the Windows 7 PC is switched off and kept as an archive. A maintenance contract then covers updates, backups and change requests.

Indicators to track

Number of modules migrated out of the total
Discrepancies found between Access totals and migrated totals
Number of days of manual invoicing
Number of users consulting stock without going through the accountant

Tech stack

Existant audité: Microsoft Access Visual Basic
Nouveau logiciel: Laravel Livewire PostgreSQL
Migration des données: Python Scripts SQL rejouables
Tableaux de bord: Metabase
Exploitation: Docker Sauvegardes quotidiennes Hébergeur choisi avec le client

Frequently asked questions

No. An Access database contains its tables, queries and forms; they can be read even without the original contractor. What is missing is found by watching the software in use with the people who work with it every day.

Because a factory cannot stop to test software. Module by module, each step is small, verifiable and reversible: if the new module causes trouble, you go back to the old one while it is fixed. The risk of a single cutover is too high for a tool whose rules are not all known.

The method is the same: audit, data extraction, verified migration, step-by-step replacement. If the ERP still has value, it can also stay at the centre while only what blocks is modernised, for example access from the workshop or the dashboards.