# ERP Cloud Migration: The Risks a CTO Should Score First > Source: https://netray.co/erp-help/cto-erp-cloud-migration-risk-assessment > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: ERP Help ## Short answer The biggest risks are not infrastructure. They are customisations that do not survive, integrations that assume the old network, data quality and volume, a cutover window the business cannot accept, licensing changes, and loss of control over upgrade timing. Score each, and decide between lift and shift, hosted private cloud or SaaS re-implementation on that evidence. ## Kind cio ## System it-leadership ## Erp ERP cloud migration (vendor-neutral) ## Module Cloud migration / Risk ## Query what are the risks of migrating ERP to the cloud ## Alternate Queries - ERP cloud migration risk assessment checklist - lift and shift ERP to Azure AWS risks - on-prem ERP to SaaS migration pitfalls - should we move our ERP to the cloud ## Applies To On-prem or hosted ERPs moving to IaaS (Azure, AWS, Google Cloud), a vendor-managed cloud, or a SaaS edition. Applies to manufacturers, distributors and other mid-market and enterprise firms. ## Steps ### Risk assessment sequence **Items:** - Define the target model: IaaS lift and shift, vendor-hosted single tenant, or multi-tenant SaaS. Risks differ sharply between them. - Inventory customisations, reports, interfaces and database-level integrations. Mark which cannot run in the target, such as direct SQL access or custom code in SaaS. - Map every integration, file drop, printer, scanner, handheld and shop floor connection, with its latency and network dependencies. - Profile data: size, quality, archiving state, and the time needed to move it. Test a full-volume copy rather than estimating. - Define the cutover constraint: the longest downtime the plant, warehouse and finance can accept, and the fallback plan. - Compare total cost over five years, including licences, hosting, support, integration rework, change in user licence metrics and exit costs. - Check security, compliance and data residency obligations, including any customer or government requirement on where data may live and who may administer it. - Run a rehearsal migration at least twice, time it, and set a go or no-go gate with business owners. ## Sections ### Customisation and integration risk **Body:** Customisations are the most common reason cloud migrations overrun. On-prem ERPs often contain custom forms, stored procedures, triggers and reports written directly against the database. A SaaS edition may not allow any of these, so each one needs to be rebuilt through supported APIs, extension points or configuration, or retired. Integrations carry a similar risk. Systems that read the ERP database directly, mapped drives, local print servers and VPN-bound shop floor equipment all assume a network layout that changes. Latency also matters: a screen or batch job that was fine on a local network can be slow when the application and database sit far from the plant. ### Data, cutover and rehearsal **Body:** Moving data is rarely the hard part; getting it right is. Duplicate customers, inactive items, unbalanced histories and unclear unit-of-measure conversions travel with you if you do not clean them. Decide how much history moves and how much goes to an archive, since this drives migration time and cost. Plan the cutover from the business backwards. A plant that runs three shifts may tolerate only a few hours of downtime, which shapes whether you use a single weekend cutover or a staged approach by site. Rehearse with timing, reconcile balances and open orders, and rehearse the rollback too, because you may need it. **Code:** Go / no-go gate (example criteria) - Two full-volume rehearsals completed within the agreed window - Trial balance and inventory valuation reconcile to source - Open orders, WIP and purchase orders match by count and value - All critical integrations pass end-to-end tests - Rollback procedure tested and owner named - Business sign-off from finance, operations and quality ### Commercial and control risk **Body:** The licensing model often changes with the move. A perpetual licence with annual maintenance becomes a subscription, user types may be redefined, and some modules or integrations are priced separately. Compare five-year cost on both paths and include the work to re-implement what you customised. In SaaS you also give up control of timing. The vendor schedules upgrades, and your integrations and extensions must keep up with their release cycle. Check how much preview time and test environment access you get, and what the exit looks like if you later want your data and history back in a usable form. ### Security, compliance and sovereignty **Body:** Moving to the cloud shifts responsibility, it does not remove it. Understand the shared responsibility split, who holds encryption keys, where backups live and which vendor staff can access the environment. Regulated manufacturers, including aerospace and defense suppliers, may have contractual limits on data location or on who may handle certain technical data, so check those requirements with compliance before choosing a region or vendor. If those limits are strict, a private cloud, a sovereign region or keeping the ERP on-prem may remain the right answer, and that is a legitimate result of the assessment rather than a failure to modernise. ## Pitfalls - Assuming lift and shift is low risk. It moves the problems with you and can add latency. - Treating customisation inventory as a late-stage task. - Estimating data migration time instead of measuring it with a full-volume copy. - Comparing only subscription price to old maintenance cost and ignoring rework and exit. - No rehearsed rollback plan, only a go-forward plan. - Ignoring shop floor and printing dependencies that were never in the architecture diagram. ## Ai Angle An AI assistant grounded in the ERP can speed up the assessment by answering factual questions from live data and metadata: which custom tables and fields exist, which reports are actually run, how many records sit in each age band, and which users depend on which transactions. ERPray is read-only by default and shows its queries, and can run on-prem. It does not decide your target model or run the migration. ## Faq ### Is lift and shift to Azure or AWS safe? **Answer:** It is often the lowest-change option because the application stays the same, but it still carries network latency, licence terms for the operating system and database, backup and security redesign. It also does not retire technical debt. Test performance with real workloads before committing. ### What is the biggest cause of failed ERP cloud moves? **Answer:** Underestimated customisations and integrations are the most commonly cited, followed by poor data quality and a cutover plan the business cannot absorb. These are all discoverable before you commit, which is why the assessment comes first. ### Should we move to SaaS or stay on-prem? **Answer:** It depends on how much you customise, how strict your data-location rules are, and how well the SaaS product fits your processes. Heavily customised or tightly regulated environments often favour a hosted or private model. Standard processes in less regulated settings suit SaaS well. ### How long does an ERP cloud migration take? **Answer:** A lift and shift can take a few months, while re-implementing on a SaaS ERP is commonly many months to more than a year depending on scope, sites and customisation. Rehearsal results are a better guide than any generic estimate. ## Search terms ERP cloud migration risks, ERP to cloud checklist, lift and shift ERP, on-prem to SaaS ERP, ERP migration cutover plan, ERP data migration risk, ERP customisation cloud, ERP cloud total cost, ERP data sovereignty --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json