The cost and risk of moving a legacy client-server ERP to the cloud are driven by data volume and quality, customisations, integrations (including hidden ones), reports, the number of users and roles, and how the cut-over is done. A single price range is meaningless until you have measured those drivers for your system.
"How much does a full migration cost?" is the question buyers ask first and the one no honest source can answer without facts about your system. This guide gives you the drivers instead, a way to measure them, and a comparison of what it costs to keep homegrown software against moving to a commercial platform. It is written for finance, operations and IT leaders in manufacturing, construction, property and distribution companies whose ERP, accounting system or portal was built or installed many years ago. For the technique choices, see legacy ERP modernization; for planning a rollback, see cloud ERP migration risks and rollback. For help with the work, see our legacy software modernization page.
Key takeaways
- Measure before you quote. Users, roles, reports, interfaces, custom code, data volume and years of history give any vendor what it needs to price.
- Hidden integrations and reports are the usual surprise. Find them from the database, not from the documentation.
- A client-server application does not become cloud software by being hosted there. Hosting it is a stopgap, not a migration.
- Migrate open items, master data and recent history. Keep older history in a read-only archive.
- Compare homegrown and commercial platforms over five years, including internal staff time and the cost of exit, not only year-one cost.
- Usually tie a hard business deadline to an integration layer, not to a full ERP replacement.
How much does a full migration from a legacy client-server ERP to a cloud ERP cost?
There is no honest single figure. Published ranges describe different scopes, and the cost is the sum of drivers specific to your system: data volume and quality, customisations, integrations, reports, users and training, and cut-over. Measuring those drivers first is what makes vendor quotes comparable. For market-level ranges by ERP route, see our ERP total cost of ownership guide.
Use the driver table below to prepare a one-page summary for each vendor. Ask each vendor to state, per driver, what they assumed and what is excluded. A quote that does not mention integrations or reports has not looked at your system.
Why is a client-server ERP different from other legacy systems?
A client-server ERP usually installs a thick client on each desktop that talks to a database server over the office network. It was designed for fast local connections, so over the internet it can be slow or unreliable. Moving it means more than moving a server.
Typical features of these systems:
- Software installed on every PC, with versions that must match the server.
- Direct database connections from the client, and often from spreadsheets and reporting tools.
- Reports and forms built in the vendor's own designer or with local tools.
- Customisations written as database procedures, client scripts or modified screens.
- Printers, label printers, scanners and file shares attached to the office network.
- A handful of staff, or one person, who know how it all fits together.
Four routes are common. You can host the existing system in the cloud and access it through remote desktops (the least change and the least benefit). You can upgrade to the vendor's cloud edition, if one exists. You can replace it with a cloud ERP. Or you can rebuild around your own processes.
What drives the cost and risk? (cost-driver table)
Cost and risk follow the same twelve drivers. The table says, for each, why it matters, what to measure and how to reduce it. No prices are given, because any figure depends on the scope you measure for your own system.
| Driver | Why it raises cost and risk | What to measure | How to reduce it |
|---|
| Data volume and history | More data means more to extract, load, check and archive, and longer cut-over | Size of each major table, years of history, number of companies or sites | Migrate open items, master data and recent history; archive the rest |
| Data quality | Duplicates, missing values, inconsistent codes and orphan records must be fixed before loading | Duplicate rate in customers, suppliers and items; blank mandatory fields; code inconsistencies | Profile early; cleanse in the source; assign business owners |
| Customisations | Custom screens, procedures and scripts must be rebuilt, replaced by standard features or dropped | Count of custom objects, who uses them, and whether standard features cover them | Review each; remove those no one uses; keep only what gives advantage |
| Integrations | Each interface needs re-building and testing, and hidden ones fail silently after cut-over | List of interfaces, direction, frequency, owner, technology | Discover from database connections and scheduled tasks; replace point-to-point links with a managed layer |
| Reports and forms | Reports often hold business rules and are hard to recreate | Number of reports, how often each is run, by whom | Retire unused ones; rank the rest; rebuild in a reporting tool |
| Users, roles and training | More roles mean more permissions, more training and more support at go-live | Users by role, locations, languages, level of change | Train by role; appoint local champions; use pilot groups |
| Infrastructure and devices | Printers, scanners, label printers and drivers need replacing or reconnecting | Device inventory at each site | Test every device type in a pilot site |
| Business process change | Moving to standard processes changes how people work | Processes that differ from the new system's standard | Decide fit-or-change per process, with an owner |
| Cut-over approach | Parallel running costs effort; a one-night switch carries risk | Tolerance for downtime, period-end dates | Cut over after period close; rehearse; define rollback |
| Compliance and records | Audit trails and retention rules must be kept | Retention periods and audit needs, confirmed with your accountant or adviser | Archive in a readable form with access controls |
| Knowledge concentration | If one person knows the system, they become the bottleneck | Who can explain each module | Document as you discover; involve them early |
| Contracts and licences | Existing support, licence and exit terms affect timing | Renewal dates, notice periods | Align the project plan with contract dates |
How do you find the hidden integrations and reports?
Look in the systems, not the documents. List every database connection and account, every scheduled task and script on the servers, every spreadsheet that queries the database, and every file that is dropped in a shared folder. Then ask the people who run month-end what they export and by when.
Practical sources:
- Database logs or connection lists, showing which accounts and programs connect.
- Scheduled tasks, job schedulers and batch scripts on servers and workstations.
- Folders where files appear and disappear (bank files, supplier orders, payroll exports).
- The reports the finance team actually runs at month-end, which are rarely the full list the system contains.
- Spreadsheets with data connections, which often hold the unrecorded rules.
Each finding goes into an interface register with an owner, a purpose and a decision: rebuild, replace, or retire.
What should you migrate, and what should you archive?
Migrate what the new system needs to run the business, and keep older history in a read-only archive that people can still search. Every extra year of history adds effort and risk. Our guide to what to migrate to a new ERP: open balances, history and archives sets out the rule and how to agree it with finance.
How do homegrown and commercial platforms compare on long-term maintenance cost?
Neither is always cheaper. A homegrown system (a custom CMS, an accounting portal, an in-house ERP) concentrates cost in people and upkeep. A commercial platform shifts it to subscription or licence, upgrades and customisation. Compare both over five years with the same scope, including internal staff time and exit.
| Cost line | Homegrown system | Commercial platform |
|---|
| Initial build or purchase | Paid up front, or accumulated over years | Licence or subscription, plus implementation |
| Security and platform updates | Your team must patch the framework, libraries and servers | Largely the vendor's job, with your testing of updates |
| Feature requests | Built by your developers or contractors | Vendor roadmap, configuration or extensions |
| People dependency | Knowledge held by a few developers; departures are a risk | Skills available in the market, but you depend on the vendor |
| Integrations | Built and maintained by you | Provided connectors, plus your own work |
| Upgrades | Whenever you choose, at your own effort | Set by the vendor; customisations must be retested |
| Documentation | Often thin | Usually available, varying in quality |
| Hosting and monitoring | Yours | Included or separate, depending on the model |
| Exit | You own it, but it may be hard to read | Depends on data export and contract terms |
A homegrown system that is well documented, tested and owned by a stable team can be inexpensive to keep. A commercial platform that you have customised heavily can be as costly. The cost to compare is the cost of the whole capability, including the risk of the one person who understands it leaving.
What does it take to modernize legacy accounting and portal systems for a homebuilder or property manager?
It takes a clear split between the accounting core and the portals, a decision on whether to keep, extend or replace each, and a sequence that does not interrupt billing or payments. The portals are often replaced first, reading from the old ledger, and the core follows.
- Accounting core. General ledger, payables, receivables and bank reconciliation. For homebuilders, job costing, purchase orders and draw schedules. For property managers, tenant ledgers, owner statements and, where required, trust-account handling. Confirm accounting treatment and any trust or escrow rules with your accountant.
- Portals. Owner, tenant, buyer, subcontractor or vendor portals, with documents, requests and statements. These are the visible part and often the first to change.
- Documents and approvals. Lien, compliance or lease documents where they apply, and approval workflows.
- Payments and banking. Payment processors, bank feeds and reconciliation.
A common sequence is to put an integration layer over the existing ledger, replace the portals so that customers see a modern service, and then migrate the accounting core at a quiet period after close. Test the opening balances with your accountant before the cut-over.
Which vendors migrate from OpenERP?
OpenERP is the earlier name of the open-source ERP now called Odoo, so migration usually means upgrading through successive versions or re-implementing on a current platform, with custom modules reviewed and rebuilt. We do not name or rank vendors; ask each for a sample assessment, a rollback plan and a reference you can call.
How should a manufacturer with a 12-month commerce deadline choose?
Work backwards from the deadline and decouple the commerce launch from the full ERP replacement. Build a stable interface over the existing ERP for what commerce needs, launch the storefront on it, and replace the ERP in phases behind it, so a late ERP project does not delay the commerce date.
For a manufacturer facing a commerce deadline:
- Define what commerce needs from the ERP: products and prices, stock availability, customers and their terms, orders, invoices and shipping status.
- Build those as a stable interface over the existing ERP, so the storefront does not depend on the old screens.
- Replace the ERP in phases behind that interface, with the commerce front end unaware of the change.
- Choose the vendor on evidence, not rank. Use evaluating a legacy modernization vendor and ask for a reference on a comparable manufacturing system.
Worked example (illustrative numbers)
A distributor runs a client-server ERP with 120 users in 6 roles, 35 regularly used reports, 9 interfaces and 14 years of history. The audit finds that 4 of the 9 interfaces were not in any document (spreadsheets and a nightly file drop), and that 12 of the 35 reports contain pricing rules. The biggest drivers are therefore interfaces and reports, not user count. The plan: document and replace the interfaces first, rebuild the 12 rule-bearing reports with the finance team, migrate open items and three years of history, and archive the rest. The figures are illustrative.
When is this the wrong approach?
A move to the cloud is the wrong step when the system works, is supported and secure, and the only reason to move is fashion. Hosting or upgrading in place may meet the need. Starting a full replacement before anyone can say which processes the business relies on is also premature: run a legacy modernization assessment first.
Glossary: Client-server, software with a program on each PC that connects to a central database. Thick client, an installed application that does much of the work locally. Interface register, a list of every connection between systems. Cut-over, the switch to the new system.
How Timeline Digital approaches this
Based in Islamabad, Pakistan, and founded in 2013, Timeline Digital delivers custom software remotely. For a legacy ERP we start with an assessment of your users, reports, interfaces and data, set the schedule from your requirements in the Plan step (there is no fixed timeframe), and can build a free pilot of 2 to 3 key modules for you to test before the final agreement. Source code transfers to you on full payment.