Representative scenarios built on our method and our direct experience in the sectors described. They do not refer to a specific identifiable client: names, quotes and any figures are illustrative. We will publish cases with real clients — with explicit consent — as they become available.
Replacing your legacy ERP while keeping the business running
A representative manufacturing scenario: choosing what to migrate, testing real orders and planning the ERP changeover around the work your business still has to do.
Scenario results
Data entry
Before
The same details entered in two or three places
After
Entered once within a shared workflow
Data to transfer
Before
All historical records, with no selection criteria
After
Checked operational data; historical records accessible separately
Tracking changes
Before
Files without a reliable change history
After
Author and date recorded for the changes that need tracking
Changeover day
Before
A date with no criteria for confirming readiness
After
Rehearsals, checks and agreed conditions for reverting
Context
You need to replace your ERP. Tomorrow's deliveries, invoices and production schedule still depend on it. Meanwhile, checking which figures to trust means asking the same people to piece together information from spreadsheets and emails. We plan the change around that daily workload.
In manufacturing, the old system holds part numbers, bills of materials, prices and orders. But a scheduling spreadsheet, a separate warehouse application and order confirmations in someone's inbox may be just as essential. We need to understand the connections: where information starts, who updates it and whose decisions depend on it.
This is a representative scenario, not an account of a particular client project. It explains how we approach the work and what you need to check before committing to a change. The before-and-after comparisons describe the intended way of working, not measured results.
The challenge
1. The same details entered two or three times. Set up a customer in the ERP, copy the details into the dispatch spreadsheet, then enter them in the labelling software. When the delivery address changes, every copy needs updating. The work of reconciling separate systems is also discussed by lemio.it (9 April 2026). We establish where each record should be maintained and where it gets copied. Connecting applications will not resolve conflicting records unless everyone knows which system takes precedence.
2. Nobody is sure which file to use. "You don't know who changed what, or when" captures the frustration described on lemio.it (9 April 2026). The price list in your inbox disagrees with the one in the shared folder. Which applies to the order you are about to confirm? Without a reliable change history, you depend on someone's recollection. We establish where prices are updated, who may change them and which changes need a record you can check later. Moving a spreadsheet into an ERP does not settle those questions.
3. Data needs decisions before it can move. The difficulty and expense of transferring ERP data are discussed on odoo-italia.org (5 December 2025). Duplicate customers, mismatched units of measure and attachments with no document reference all need attention before import. Underestimating this work is also a risk raised by kubee.it (30 June 2026). We give each issue to someone who can resolve it, then check that the correction still holds when we repeat the transfer.
4. The working day carries on. Orders arrive, goods leave and stock levels change while we prepare the replacement. Data used in a rehearsal soon becomes out of date. We need a plan for bringing across subsequent changes and a clear point at which entries in the old system stop. Parallel running also needs an end date, or it becomes another permanent job.
The numbers worth checking
We help you establish how much work the current arrangement creates before choosing its replacement. Use the same scope for later comparisons and record how you arrive at each answer.
- How many hours a week go on copying data and reconciling systems? Track an actual working week, separating entry from corrections.
- How many potential duplicates are there in your customer and product records, and how many do you confirm after checking them?
- How many orders need correcting after entry, out of all orders in the period? Separate price, quantity, product code and address errors.
- How many days after month-end are checked figures available for decisions?
- How many applications do you open to take an order through to invoicing, including spreadsheets and email?
- How many people can extract the records you need and check that the export is complete?
- How long does it take to confirm an item's availability, allowing for stock already allocated to orders?
The approach
1. Agree what the new system needs for daily work. We work with you to separate operational records from history that only needs to remain accessible. The scope includes customer and product records, outstanding orders, customer and supplier balances, stock, bills of materials, production routings, prices and commercial terms. Each set needs someone responsible for it, agreed checks and a destination.
Recent activity alone is not a sufficient selection rule. A component with no recent movements might still appear in a valid bill of materials. We check those dependencies. We also agree how you will find historical documents and attachments, who needs access and where the records will sit. We test retrieval before the old system is retired.
2. Rehearse the import against agreed checks. We document how fields in the old ERP correspond to fields in the new one, including any conversion rules. Each rehearsal checks imported records, rejected entries, quantities and balances. A technically successful import can still contain incorrect data.
Corrections go into the source records or preparation files so that we can repeat the procedure reliably. There is no fixed number of rehearsals that guarantees readiness. We proceed when the agreed checks pass and any exceptions have a documented decision. Someone who understands the records must verify their content; an on-screen success message is not enough.
3. Test everyday work on a limited scope. Together, we select a product family, department or customer group. We follow real orders through dispatch and invoicing, comparing what happens in each system. Less frequent cases matter too: a partial delivery or a price amendment can expose rules that people have never needed to write down.
For each activity, we specify which system provides the authoritative record and how to prevent duplicate documents or stock movements during the parallel run. Your team needs time allocated for this work. Fitting it around whatever is left at the end of the day is not a workable plan.
4. Confirm the date when the evidence supports it. We agree a changeover window and who makes the decision to proceed. The plan specifies when entries stop in the old system, when the final export happens, what gets checked and which failures require postponement. A date helps everyone prepare; it does not override a failed check.
We also prepare for a return to the old system: who can authorise it, how data will be restored and how transactions already entered in the replacement will be recovered. We test restoration before the changeover. Once the move is confirmed, the previous system remains available on a read-only basis for the agreed period, with someone responsible for access.
What changes
The practical test is whether opening an order gives you its status, stock availability and related documents without a search through emails and spreadsheets. That depends on configuring the workflow, checking the connections between applications and recording each transaction in the agreed place.
For significant changes, such as prices and terms, we specify what the history must capture and check that you can see who changed what and when. We do not assume every field has a usable history by default.
After the launch, we revisit the questions above. If you still copy a record elsewhere, we investigate the missing step. If a stock figure looks wrong, we trace the movements behind it. How often you still need to check outside the ERP is part of the assessment.
What people fear, and what we say
"What if records are missing or the figures don't reconcile?" We distinguish missing data from inconsistencies already present in the source. Each discrepancy needs an explanation, an assessment of its consequences and someone responsible for deciding how to resolve it. Your finance team validates balances, involving advisers where needed. We do not accept unexplained differences as inevitable. If they prevent essential work or undermine records you need, we postpone the move.
"We can't afford to stop." We schedule rehearsals and the changeover around orders, deliveries and deadlines. With you, we also agree how urgent work will be handled during the final transfer. We cannot promise there will be no slowdown: people need practice, and training takes time. Support, clear priorities and a manageable workload need to be in place for the launch.
"Will adapting the software make upgrades difficult?" We start with standard features and assess each proposed change against the work you need to do. We will tell you when a request simply recreates an old habit. Where a change is necessary, we document the reason and plan checks for future upgrades. Keeping modifications separate makes maintenance easier; it does not make it free.
How we approach it today
Start by showing us an order from arrival to invoice, the files that accompany it and the figures you have to check elsewhere. That gives us a basis for deciding what to investigate before estimating the work and timescale. You can read more about our ERP and sales work here:
Let's talk — 30 minutes, with no obligation. Tell us where you keep having to copy data or chase an answer. We'll start with that.
Declared limitations
Transparency is part of our method. Here's what this scenario doesn't prove.
- The before-and-after comparisons describe the aims of a representative scenario, not measured client results. Assessing timescales and benefits requires evidence of how the business currently works.
- Data cleaning, testing and training take time from your team. Running systems in parallel adds data entry and checks to their regular workload.
- Access to data and attachments depends on the outgoing system and the supplier contract. Exporting records and retaining access to historical data may involve additional charges.
- A read-only archive needs maintenance and access checks. Arrangements for retaining tax documents still need to be managed with the company's advisers.
- Changes to the software need maintenance and testing whenever it is upgraded. Documentation and keeping those changes separate reduce future work; they do not remove it.
Want similar results for your company?
In 30 minutes, we'll discuss how your business works and whether the AIRA method fits your needs.