What Cloud Migration Means for an ERP
Cloud migration means moving your ERP and its data off servers in your office, or off desktop software installed on a few PCs, into a cloud environment your team reaches through a browser. For a small company it might be moving from an accounting package on the accountant's computer to an integrated cloud ERP. For a multi-branch group it can mean moving a ten-year-old on-premise system with years of customisations and reports.
Whether to move at all is a separate question, covered in our comparison of cloud and on-premise ERP. This guide assumes the decision is made and focuses on the harder part: getting there without interrupting invoicing, losing customer balances, or having your auditor discover six months later that opening stock does not match the books.
We cover the main migration approaches, a phased plan, what to do with historical data, the reconciliations to run before go-live, the Saudi regulatory points that affect a move, and a sample timeline. The numbers in the examples are hypothetical.
Migration Approaches
There are several recognised ways to move a system to the cloud. The right one depends on what you are moving from:
| Approach | What happens | When it fits | Main risk |
|---|---|---|---|
| Rehost (lift and shift) | Run the existing system as is on cloud servers | A fairly modern system where you just want out of server management | Old problems move with you and you gain little beyond hosting |
| Replatform | Limited changes so the system runs on cloud infrastructure | A custom system with real value you do not want to lose | Ongoing development and maintenance cost |
| Replace with cloud ERP | Move to a ready-made cloud ERP | Legacy software, scattered tools, or customisations nobody understands | Process change that needs managing and training |
| Retain or retire | Keep a component local, or switch it off | Modules no longer used, or with special constraints | Isolated islands of data remain |
For most small and mid-sized companies in the Kingdom, replacing with a cloud ERP is the practical route. Older local systems usually need significant work anyway to keep up with e-invoicing and government integrations, so the move becomes a chance to reorganise processes instead of transplanting the mess.
Phase 1: Inventory What You Have
Before discussing data transfer, know exactly what exists:
- Systems. Not just accounting, but the spreadsheets running payroll or project tracking, and the small tools at the POS or in the warehouse.
- Data. Counts of items, customers, suppliers, employees and assets, and how many financial years are stored.
- Integrations. What connects to the current system: bank files, an online store, attendance devices, the e-invoicing connection.
- Reports. Ask each department for the reports it actually uses every month. You will often find half the custom reports have not been opened in a year.
- Customisations. For each one, ask whether you still need it and whether the new system covers it out of the box.
The output is a short scope document: what moves, what stays behind, and what gets redesigned.
Phase 2: Clean Before You Move
This is the most underestimated phase and the one with the most influence on success. Bad data in the old system becomes bad data in the new one, with migration costs added.
- Duplicates. The same customer entered three times with slightly different names, or one item under two codes.
- Missing fields. Business customers without a VAT number or full address, which a tax invoice to a VAT-registered buyer needs.
- Dead records. Items with no movement in three years, suppliers you have not bought from in ages. Migrate them as inactive or leave them behind.
- Unresolved balances. Old invoices never closed, unmatched payments, suspense accounts nobody can explain. Settle them before migration, not after.
- Chart of accounts. A chance to review it. Accounts added for a one-off purpose that stayed, or structures that do not support the reports management wants.
Picture a Riyadh trading company with 6,200 items in its old system. Review shows 1,900 have not moved in over two years and 340 are duplicates. Only 3,960 active items go across. Migration and testing get lighter, and staff see cleaner item lists from day one.
Phase 3: Decide How Much History to Bring
Every project hits this question: do we migrate every transaction since the company started? Usually, no. The common options:
| Option | What moves | Pros | Cons |
|---|---|---|---|
| Opening balances only | Master data, trial balance and open items at cutover | Fastest, lowest risk | Comparative reports need the old system |
| Monthly balances for prior year | The above plus monthly totals per account | Year-on-year comparisons in the new system | Moderate extra effort |
| Full transaction history | Every historical journal and invoice | Everything in one place | Slow, costly, and imports past errors |
The balanced choice is usually opening balances plus prior-year monthly totals, with the old system kept read-only or its data exported to a structured archive. Commercial books must be retained for ten years under the Commercial Books Law, so do not decommission the old system or delete data without an archiving plan.
What always has to move
- Master data: customers, suppliers, items, employees and assets.
- The trial balance at the cutover date.
- Open customer and supplier invoices, each one individually rather than as a lump balance, so they can be collected, paid and aged.
- Stock quantities and costs by warehouse.
- The fixed asset register with cost, accumulated depreciation and remaining life.
- Employee leave balances and end-of-service provisions.
- Open purchase orders and sales orders.
Phase 4: Choose a Cutover Strategy
- Big bang. The old system stops on a set date and everything runs on the new one the next day. Quickest and cheapest, but only safe with thorough testing beforehand.
- Phased. Module by module, for example finance first then inventory then payroll, or branch by branch. Less risk per step, but you need temporary bridges between the two systems.
- Parallel run. Both systems run for a month, everything entered twice, then compared. It sounds safe, but it exhausts staff, and serious comparison usually stops after week two.
For SMEs, a big bang cutover at the start of a month, ideally the start of a quarter or financial year, backed by full testing, is usually the most practical.
Picking the date
The start of the financial year is ideal, because opening balances are clean after year-end close. If that is not possible, pick the start of a VAT quarter so one return is not split across two systems. Avoid your peak season: a food distributor should not go live two weeks before Ramadan, and a contractor should not cut over in the week major progress claims are due.
The Project Team
An ERP migration is not an IT project. The ones that go well are usually led by someone from finance or operations, with a representative from every department that will use the system:
- Sponsor: a senior executive who can settle disputes between departments and approve process changes.
- Internal project manager: runs the schedule, collects decisions and makes sure departments deliver their data on time.
- Key users: one each from accounting, warehouse, sales and HR. They test, then train their colleagues.
- Data owner: decides what moves and what stays, and oversees cleansing.
- Vendor team: an implementation consultant who knows the new system and a data migration specialist.
If key users are expected to do their full day job plus the project, expect delays. Take some of their routine work off them during testing weeks.
Budgeting the Migration
The subscription is only one cost line. A realistic budget includes:
- Vendor setup, implementation and training fees.
- Data migration, especially when data sits in several sources.
- Customisations and integrations not available out of the box.
- Internal staff time, which is a real cost even though no invoice arrives for it.
- Keeping the old system available read-only during transition.
As an illustration: four key users giving 30% of their time for three months, at an average monthly cost of SAR 12,000 each, is roughly SAR 43,000 of internal effort. Leaving it out makes the project look cheaper than it is, and makes it tempting to cut testing time when daily work gets busy.
Phase 5: Test and Reconcile
Run at least one trial migration, preferably two, loading real data into a test environment and reconciling it. The minimum checks:
| Reconciliation | What must agree |
|---|---|
| Trial balance | Every account, new system vs old, at cutover date |
| Receivables | Total open invoices vs the receivables control account |
| Payables | Total open supplier invoices vs the payables control account |
| Inventory | Quantity × cost across all items vs the inventory account |
| Fixed assets | Register cost and accumulated depreciation vs the ledger |
| Bank | Book balance vs statement after reconciling items |
Then test real processes end to end: a sales order through to tax invoice and receipt; a requisition through to goods receipt, supplier invoice and payment; a complete payroll run. The people who will use the system every day should run these tests, not just the project team.
Saudi Regulatory Points
E-invoicing
If your company is in Phase 2 of e-invoicing, the integration phase, changing the system that issues invoices is not purely internal. The new solution has to be onboarded to the Fatoora platform and receive its cryptographic stamp identifier before it issues its first invoice. Put that step into the plan well before go-live and test it in the sandbox first. Integration has been rolled out in waves: businesses with turnover above SAR 375,000 were in Wave 24, integrating between April and June 2026. See our e-invoicing guide for details.
Personal data
The Personal Data Protection Law has been in force since September 2023, with enforcement starting after a one-year grace period. Employee data and individual customer data moving to the cloud is personal data. Ask your provider where data is hosted, who can access it and how it is deleted when the contract ends.
Cybersecurity and cloud rules
The National Cybersecurity Authority has issued Cloud Cybersecurity Controls (CCC-2:2024). Separately, the Cloud Computing Regulatory Framework classifies government data into defined levels and does not allow it to leave the Kingdom. If you work with or for government entities, check your contract terms before choosing where data is hosted.
A Sample Timeline
A mid-sized distributor with 45 users and three warehouses moving from local accounting software and spreadsheets to a cloud ERP:
| Weeks | Activity |
|---|---|
| 1 to 2 | Inventory, assessment and scope |
| 3 to 5 | Data cleansing, chart of accounts review, system configuration |
| 6 to 7 | First trial migration and reconciliation |
| 8 to 9 | Process testing with key users, configuration fixes |
| 10 | Role-based training and second trial migration |
| 11 | E-invoicing onboarding in production, period close in old system |
| 12 | Final migration and go-live |
| 13 to 16 | Hypercare support and first month-end close on the new system |
Real timelines vary a lot with data quality and staff availability. The most common cause of delay is not technical. It is people too busy with daily work to clean data and test.
Mistakes That Keep Repeating
- Migrating without cleansing. Faster at first, then months of corrections after go-live.
- Skipping trial migrations. The first time you load data should never be the real one.
- Lump-sum receivables. When a customer calls about a specific invoice, it is not there.
- One training session for everyone. Storekeepers do not need journal entries; accountants do not need receiving in detail. Train by role.
- Switching off the old system too soon. Keep it readable at least until the first year-end close and audit.
- Ignoring change management. People who have worked one way for years need to understand why it changed. We cover this in ERP change management.
After Go-Live
Go-live is not the finish line. The first weeks decide whether people actually use the system or drift back to spreadsheets. Assign a clear support team for the first two months, review recurring errors weekly, and treat the first month-end close on the new system as a planned event. Our first 90 days guide lays out a plan for this period.
Tranquil is a cloud ERP covering accounting, e-invoicing compliant with Phases 1 and 2, inventory, sales, purchasing, HR, payroll, projects and assets. We also provide customisation and API integrations, and certified role-based training on-site or remote with 30 days of post-training support. To discuss your migration plan, contact us.
Frequently Asked Questions
How long does a cloud ERP migration take?
For an SME with reasonably clean data, typically two to four months. Larger companies with many customisations and branches may need longer.
Do we have to migrate all historical data?
No. A common approach is opening balances and open items plus prior-year monthly totals, with the old system or a structured archive kept for reference, bearing in mind the ten-year retention rule for commercial books.
When is the best time to switch?
The start of a financial year. Failing that, the start of a VAT quarter, away from your busiest season.
Does changing ERP affect e-invoicing?
Yes, if you are in the integration phase. The new solution must be onboarded to Fatoora before it issues invoices, so schedule and test that step before go-live.
What happens to systems connected to the old ERP?
Every existing integration, such as bank files, an online store or attendance devices, has to be rebuilt or replaced. That is why integrations belong in the first phase inventory, not on the go-live checklist.