A furniture manufacturer bought its ERP together with a package of bespoke developments. Four years later, moving to the next release in the same product family, it paid for those developments a second time. Its head of administration sums the episode up in one line: you buy the software, you commission all the work, and a few years on you pay for it again. That is where ERP customisations stop looking like a contractual detail and start behaving like a recurring cost.
Six years went by before the same company learned that a far more recent release existed. Nobody had adopted it, for a precise reason: with several ERP customisations in place, no supplier would guarantee they would be carried across. Volumes, sites and headcount kept growing while the software stood still. By the time a platform review finally opened, everything the system no longer covered had migrated into spreadsheets and mailboxes.
Whenever a company assesses replacing its ERP platform, the question about customisations comes before the question about price. A business with twenty years of procedures inside a piece of software fears losing them; a business that has already rebuilt them once fears doing it again at the next release. Two concrete variables decide the answer: what was customised, and by what technique.
Configuration and bespoke ERP customisations lead to different outcomes
Most requests are settled without writing a line of code. Cleaner forms, reordered columns, reorganised panels, mandatory fields, redesigned print layouts, filters and totals saved per user: all of these are settings, and they live in the configuration layer. An upgrade leaves them alone.
Bespoke development belongs somewhere else. It alters how the program behaves, adds logic the standard product does not provide, and needs realigning whenever the vendor ships a new version. ERP customisations built this way carry a cost at every release. Negotiations almost always blur the distinction: the client describes a need, the supplier answers with a quotation, and nobody states which of the two layers the work sits on.
On the ERP projects we run at Aesir Srl, that separation is the first thing we put in writing. How much of the request is covered by configuring the standard, how much needs an extension, and how much needs a genuine modification. Each of the three carries a different cost, a different timeline and, above all, a different fate at upgrade time.
Comparing the cost of ERP customisations across the three categories
Three examples from the same project make the difference visible. Adding a warehouse grid column that shows the supplier’s own article code is configuration: set once, and it stays. Creating a new accounting code alongside the standard ones, to separate subcontracting invoices, is an extension: it sits beside the product and survives the release. Changing the algorithm that calculates stock availability is a genuine modification: it touches the core, and every new version someone has to check that it still behaves as intended.
Cost follows the same scale. Configuration carries an analysis cost and no recurring cost. An extension carries a build cost and a light check at each release. A core modification carries a build cost, a realignment cost at every release, and a regression cost, meaning the hours spent confirming the upgrade has not changed expected behaviour. When two quotations sit side by side, ask for the three lines separately: nothing else shows which offer is cheaper in year three.
Which ERP customisations survive an upgrade?
Customisations obtained by configuring the standard, or by placing new objects beside it, survive. Those that alter system objects have to be rebuilt, because the release overwrites them.
During analysis we apply a rule that few clients accept at the first meeting: system objects are never modified, they are duplicated. Standard accounting codes and VAT codes stay untouched; when different behaviour is needed, new ones are created using the existing entries as a template. On the chart of accounts, the choice lies between hiding a line and deleting it: hiding wins, because a line removed today may be needed for a tax inspection three years from now.
A twenty-person family business with three divisions and job-based production arrived at migration with a clear instruction from its accountant: adopt the new ERP’s standard chart of accounts rather than rebuild the old one, so that every upgrade lands cleanly instead of turning into a mess. During the previous migration they had done the opposite, and their verdict on the result fits in one line: the system loses its automations.
| Type of work | Where it lives | Behaviour at release |
|---|---|---|
| Configuration of forms, columns, filters and print layouts | User profiles and parameters | Preserved |
| New objects created by duplication: accounting codes, tables | Extended system records | Preserved |
| Modification of standard objects shipped by the vendor | Product core | Overwritten, needs realigning |
| Integration layer towards external applications | Separate component | Review at every API change |
Twenty years of procedure inside software that no longer updates
The furniture manufacturer’s story closes on a detail that matters more than the repeated invoice. Those re-purchased developments covered kits and in-house production, and the company settled the bill shortly before moving production out: losing them changed nothing. What slows the warehouse down every day is a different piece of work, the interface between the handheld stock system and the ERP, and nobody ever built it. Of all the ERP customisations discussed over those years, it is the only one no one ever signed a quotation for.
A B2B distributor with its own sales network has run bespoke software for twenty-five years. Its product manager describes the situation without softening it: the company is starting to feel cramped inside the shell it built for itself. He asks the supplier the question everyone asks, whether the starting point is a standard product or something written from scratch each time. Ownership then paused the project for the current year, and the stated reason is not the platform under review but the weight of twenty-five years of layering. Every function added over time made that software fit the business better and made it harder to replace: the second effect always arrives after the first, and nobody budgets for it when signing the first customisation.
ERP customisations set project timelines more than modules do
Customisations drive the project calendar more than any other item, because each change has to be analysed, built, tested and explained to the people who will use it. Timing estimates therefore belong alongside the decision about what to customise, not after it.
The sequence itself is well established: overview demo, detailed analysis with a firm estimate, request for a database copy from the outgoing supplier, alignment on chart of accounts, accounting codes and VAT codes, master data import, configuration, training, go-live. One variable sits outside the supplier’s control.
That variable is the availability of whoever knows the processes. On a project scheduled to go live on 1 January, both parties agreed half a day a week for the administrative lead, in planned sessions, so her workload would not be disrupted without warning. On the same basis the supplier asked to start roughly a month earlier than the client had proposed. Training was kept out of the weeks immediately before the summer break, for the most practical reason of all: by September nothing survives.
Early weeks after go-live absorb far more effort than steady state. On projects that went live in January, contact with support is close to daily through the first quarter and then falls away. A narrow piece of configuration, such as bank reconciliation with two connected institutions, takes around a day, with banking consent renewed every three or six months depending on the bank.
Tickets work at steady state, go-live needs a direct line
Resistance to ticketing always sounds the same: fine to open tickets, but not too much bureaucracy, and please let us find a supplier who speaks our language. It is a fair request, and separating the phases answers it.
During onboarding the exchange is direct and skips the ticket queue, because the project has a named contact and a rhythm of its own. At steady state ticketing becomes the right instrument: it records the activity, assigns it to the first available engineer, and carries the list of software active at that client, so whoever picks the request up already knows what they are dealing with. More than one channel stays open, from the portal to the mailbox that raises a ticket automatically to the telephone. Escalation triggers when resolution misses the agreed window.
Different engineers cover different application areas, each specialised on their own product across ERP, CRM and document management. Aesir operates as MSP and MSSP within a single contractual perimeter, on projects across Italy.
Integrating vertical systems without replacing them
The second recurring question concerns the software a company has no intention of touching. A proprietary B2B portal, a visit planning application, an HR vertical: systems that work and that internal people know well.
APIs answer that question. With the distributor described above, portal and visit planning stayed outside the perimeter by explicit instruction, and the project was built around that constraint with a dedicated integration layer. With an HR vertical the flow runs both ways: attendance data rises into the ERP, jobs descend into the vertical, and creating or deleting a job is the event that triggers synchronisation. Access opens by generating a token, which takes minutes.
One decision remains: which system owns the master record. Where an ERP and a time and attendance system coexist, the ERP holds the reference data, and exceptions are allowed at individual document level. Aesir is a Gold Partner of NTS Informatica for Business Experience, and with other business software we use the available connectors or build them.
Checklist: which ERP customisations to approve and which to postpone
Six points are worth checking before signing a development quotation.
- Can the request be met by configuring the standard? Ask for that assessment in writing, not over a call.
- Does the work modify an object shipped by the vendor, or create a new one by duplication?
- What happens to that function at the next release, and who carries the cost?
- Does the change serve a process that will stay, or an activity the company is considering outsourcing?
- Is there documentation a different supplier could read without the original author?
- Has the maintenance window been agreed, or do releases arrive unannounced during working hours?
That last point creates more friction than any other. Regulatory updates can be released automatically outside working hours, or manually for anyone who prefers a conservative approach with agreed windows. Tax deadlines and e-invoicing requirements published by the Italian Revenue Agency, the Agenzia delle Entrate, arrive regardless; the only variable a company controls is when the system pauses to take them.
Questions that come up during analysis
Can existing ERP customisations be moved to a new platform?
They do not transfer as objects. What transfers is the requirement behind them, and against that requirement you check how much the new platform already covers as standard. On many projects the remainder to be built is far smaller than the original, because the product has since absorbed as standard what once needed bespoke work.
Does updating an existing development cost as much as rebuilding it?
On an evolutionary product that keeps continuity between releases, realigning an existing development takes less effort than rewriting it. The condition is that the change is documented and built on top of the standard. Without documentation the effort tends to match a fresh build.
What happens to the data if the supplier relationship ends?
The supplier returns a copy of the database. Check that clause before signing, together with the format the data arrives in: a proprietary backup, unreadable without the software that produced it, satisfies the wording and helps nobody who has to move the data elsewhere.
Let’s talk
ERP customisations are not a mistake to avoid. They are a legitimate answer to a process a company has built and that sets it apart from competitors. What matters is the horizon: every bespoke development should be judged on its maintenance cost across the whole life of the system, which for business software is measured in years. Choosing configured standard costs less on day one and considerably less at the first upgrade.
If you would like to explore the subject or assess the situation in your own company, you can fill in the form at the bottom of this page or write to support@aesir-tech.it: we will arrange a free consultation and start from your numbers.