# On-Premise ERP to Cloud Migration: Timeline, Risks & Real Cost Breakdown On-premise ERP systems were designed for a world where data lived in one building, users sat at desks inside that building, and the software ran on servers you could physically touch. That world is... ## On-Premise ERP to Cloud Migration: Timeline, Risks & Real Cost Breakdown Migrating from on-premise Epicor, Infor, Sage, or custom ERP to cloud infrastructure takes 12–24 months and costs $250K–$2M+ for mid-market manufacturers. Lift-and-shift, re-platform, and re-implement each carry different risk profiles, and 55–75% of ERP cloud migrations exceed their original budget. This is the guide we wish someone had given every IT Director before they signed the SOW. --- ## Our Process 1. **Technical Discovery & Migration Path Analysis (2–4 Weeks)** — We conduct a deep technical audit of your existing on-premise ERP environment. This includes server infrastructure assessment (hardware age, OS versions, database versions, storage capacity and utilization), application assessment (ERP version, installed modules, patch level, license structure), customization inventory (every stored procedure, custom form, report, workflow, and integration cataloged and classified), data assessment (database size, table count, data quality issues, historical data volume), and integration mapping (every system connected to the ERP, the connection method, data flow direction, and transaction volume). We interview IT staff, power users, and department heads to understand which capabilities are business-critical versus nice-to-have. Deliverable: a migration strategy document with cost-timeline-risk analysis for all three paths (lift-and-shift, re-platform, re-implement) and a recommended approach with specific justification. 2. **Cloud Platform & Vendor Selection (2–6 Weeks)** — If the chosen path is re-platform or re-implement, we help evaluate target platforms through structured RFP processes and proof-of-concept exercises. For re-platforming, this means selecting cloud infrastructure (Azure, AWS, or GCP) and managed services. For re-implementation, this means evaluating cloud-native ERP platforms against your requirements — Epicor Kinetic for discrete manufacturing, Infor CloudSuite for process manufacturing, Dynamics 365 F&O for multi-entity enterprises, NetSuite for high-growth mid-market. We run 2–4 week proof-of-concept pilots focused on your most complex business processes (not the vendor's canned demo data) to validate that the target platform can handle your edge cases before you sign a multi-year licensing agreement. 3. **Customization Rationalization & Gap Analysis (3–6 Weeks)** — Every customization in your legacy system gets classified into one of four categories. Category 1: Retire — the customization was built to work around a limitation that no longer exists in the target platform (typically 20–35% of customizations). Category 2: Replace — the target platform has a standard feature that accomplishes the same outcome with configuration, not custom code (typically 25–40%). Category 3: Rebuild — the customization encodes unique business logic that no standard feature addresses, and it must be rebuilt as custom development on the new platform (typically 20–35%). Category 4: Re-evaluate — the customization exists but the business process it supports may no longer be necessary (typically 5–15%). This analysis directly determines the custom development budget for the project. Skipping or shortcutting this phase is the number one cause of mid-project budget blowups. 4. **Data Migration Design & Execution (4–10 Weeks)** — Data migration runs in three passes minimum. First pass: schema mapping and transformation rule definition. We map every source table and field to the target system's data model, define transformation rules for fields that do not map directly, and build the ETL (extract-transform-load) pipeline. Second pass: test migration with a subset of data. We migrate a representative sample, validate it against the source, and identify mapping errors, data quality issues, and transformation edge cases. Third pass: full test migration with complete data, including a reconciliation cycle where we verify record counts, financial balances, inventory quantities, and open order totals match between source and target. Production migration is a fourth and final pass, typically executed over a weekend or planned downtime window. For manufacturers with 10+ years of transactional data, we recommend migrating detailed transactions for the most recent 2–3 fiscal years and summary balances for older periods to reduce migration time and target system bloat. 5. **Integration Rebuild & Testing (4–8 Weeks, Overlapping with Data Migration)** — Every integration connected to the legacy ERP must be re-pointed to the new cloud system. Direct database connections are rebuilt as API integrations (the cloud ERP will not allow direct DB access). Flat file integrations are evaluated for replacement with real-time API connections or maintained as file-based if the counterpart system has no API capability. EDI connections are remapped to the new system's EDI module or rebuilt through a modern EDI translator. Middleware layers are reconfigured to route through the new system's API endpoints. Each rebuilt integration goes through unit testing, integration testing with sandbox data, and volume testing at 2–5x expected production throughput before go-live. 6. **User Training & Parallel Running (4–12 Weeks)** — Training begins 4–6 weeks before go-live with role-based sessions. We do not run generic training where everyone sees everything. Shop floor users get shop floor training. Purchasing gets purchasing training. Finance gets finance training. Each session uses your actual migrated data and your actual business processes, not generic examples. Parallel running begins 2–4 weeks before cutover: users process real transactions in both old and new systems, and we run daily reconciliation reports comparing outputs. Go/no-go decision is made based on pre-defined criteria: financial close accuracy within $1,000, inventory valuation within 0.5%, MRP recommendations matching within 95%, and zero critical-path process failures. If criteria are not met, cutover is postponed — not forced through. 7. **Production Cutover & Hypercare (2–4 Weeks Post-Go-Live)** — Cutover typically happens over a weekend or scheduled plant shutdown. Friday close: final transactions processed in legacy system, end-of-day backups, database freeze. Saturday: production data migration (delta records since last test migration), integration cutover, system validation. Sunday: smoke testing by power users, final reconciliation. Monday: go-live with on-site support from the project team for every department. Hypercare runs 2–4 weeks: daily check-ins with department leads, priority escalation path for issues, same-day resolution SLA for any production-blocking problems. Post-hypercare transitions to standard support and optimization cycles. --- ## Frequently Asked Questions ### How much does it really cost to migrate on-premise ERP to the cloud? Total cost depends entirely on which migration path you take and the complexity of your existing system. Lift-and-shift (rehosting your current ERP on cloud VMs) is the cheapest at $50,000–$200,000 for mid-market manufacturers with 50–300 users, but it is a tactical bridge, not a permanent solution. Re-platforming (moving to cloud infrastructure while modernizing specific layers) runs $150,000–$600,000. Full re-implementation on a cloud-native ERP platform costs $500,000–$2,000,000+ and that number does not include the cloud ERP subscription fees themselves, which typically run $150–$300 per user per month for manufacturing-specific platforms. The hidden costs that blow budgets are almost always the same: data migration ($50K–$150K when you have 10+ years of transactional history), customization rebuilds ($2K–$25K per customization depending on complexity, multiplied by 50–200 customizations), integration rebuilds ($5K–$25K per connected system), change management and training ($30K–$100K for 100+ user organizations), and the parallel running period where you are paying for both old and new systems simultaneously (2–6 months of double licensing and infrastructure costs). When Rimini Street reports that 74% of organizations underestimate cloud ERP costs by 2–4x, these hidden workstreams are the reason. ### How long does an on-premise to cloud ERP migration take? Lift-and-shift takes 3–6 months from planning to production cutover. Re-platforming takes 6–14 months. Full re-implementation on a new cloud-native ERP takes 12–24 months, with 18 months being the median for mid-market manufacturers with 100–300 users and moderate customization complexity. The phases that take longest are almost never the technical migration itself. Customization rationalization and gap analysis takes 3–6 weeks and is the most important phase of the entire project — shortcutting it is the primary cause of timeline blowups later. Data migration requires 3–4 full test cycles (each taking 1–2 weeks) before the production cutover is reliable. User training needs 4–6 weeks of structured sessions before users can operate the new system competently. And parallel running — operating both systems simultaneously to validate outputs — adds 4–12 weeks depending on your industry's tolerance for risk. Panorama Consulting's data shows that 67% of ERP projects take longer than expected, with the average overrun being 30%. We build that overrun expectation into our timelines from day one rather than presenting an optimistic estimate and then requesting extensions. ### Should we lift-and-shift first and re-implement later, or go straight to re-implementation? The two-phase approach (lift-and-shift now, re-implement later) makes sense in two scenarios. First, if you have a hard infrastructure deadline — your data center lease expires in 6 months, your server hardware is failing, or you lost your sysadmin and cannot maintain the on-premise environment — lift-and-shift buys time while you plan the larger project. Second, if your organization has never done a major ERP migration and you want to reduce the amount of simultaneous change: moving to cloud infrastructure is one change, and switching to a new ERP platform is a separate change that happens 12–18 months later. The downside is cost: you pay for the lift-and-shift ($50K–$200K), pay higher monthly cloud IaaS costs to run the old ERP on cloud VMs (typically $3,000–$8,000/month for mid-market manufacturers), and then pay the full cost of re-implementation when you are ready. Going directly to re-implementation is more cost-efficient over 3–5 years but requires the organizational readiness to absorb a larger, longer project. Our recommendation: if you have 12+ months before your infrastructure becomes critical, go straight to re-implementation. If you have less than 6 months, lift-and-shift first. ### What happens to our customizations when we migrate to cloud ERP? This is the question that determines whether your cloud ERP migration costs $300K or $1.5M. The average mid-market manufacturer running an on-premise ERP for 10–15 years has 50–200 customizations including custom forms, stored procedures, reports (Crystal Reports, SSRS), workflow automations, custom dashboards, EDI maps, and integration connectors. In a lift-and-shift, customizations carry over as-is because you are running the same application code. In a re-platform or re-implement, every customization falls into one of four categories. Retire (20–35%): the customization works around a limitation that the cloud-native version has solved with standard features. Replace (25–40%): the target platform has configurable features that achieve the same outcome without custom code. Rebuild (20–35%): the customization encodes unique business logic that no standard feature covers and must be rebuilt on the new platform. Re-evaluate (5–15%): the customization supports a business process that may no longer be necessary. The customization rationalization phase is where the biggest savings are found. We have seen projects where 40–50% of legacy customizations were eliminated, saving $150K–$400K in rebuild costs. The trap to avoid is the implementation partner who tells you all customizations will be standard in the new system. That is never true. Get the gap analysis done before you sign the implementation contract. ### How do we handle data migration from a 15-year-old on-premise ERP? Data migration from a long-running on-premise ERP is the most technically complex and most underestimated workstream in the entire project. After 15 years, your database contains orphaned records from deleted customers, duplicate entries from system conversions, fields repurposed from their original intent, custom tables that only one person understands, and data quality issues that were papered over by manual workarounds and tribal knowledge. The first decision is scope: how much historical data do you actually need in the new system? Moving every transaction from the last 15 years into a cloud ERP with a different data model is technically possible but expensive ($100K–$150K+ in ETL development and validation) and often unnecessary. Most manufacturers need detailed transaction history for the current and prior 2–3 fiscal years, summary balances (AR, AP, inventory, GL) going back further for audit purposes, and master data (customers, vendors, items, BOMs, routings) in full. We build the migration as a repeatable ETL pipeline that runs multiple test cycles. Each cycle migrates data, runs validation scripts that compare record counts, financial totals, inventory valuations, and open document balances against the source system, and produces a discrepancy report. Typical projects require 3–4 full test migration cycles before the reconciliation passes cleanly enough for production cutover. ### What is the failure rate for ERP cloud migrations? It depends on how you define failure. If failure means the project was abandoned entirely and the company reverted to the legacy system, the rate is relatively low — roughly 5–10% based on industry data from Panorama Consulting and Gartner. If failure means the project went live but exceeded its original budget by more than 25%, the rate is 40–55%. If failure means the project went live but did not deliver the functionality, performance, or user adoption that was promised, the rate climbs to 55–75%. The most common failure modes in on-premise to cloud ERP migrations are remarkably consistent: inadequate customization analysis (discovering mid-project that 30 critical customizations have no equivalent in the new system), insufficient data migration testing (going live and discovering that inventory valuations or financial balances do not match), underestimated change management (users refusing to adopt the new system and creating shadow spreadsheets), integration failures (connected systems breaking because the new ERP's API behaves differently than the old system's direct database connections), and scope creep from departments that did not participate in requirements gathering but surface critical needs after development is complete. Every one of these failure modes is preventable with rigorous upfront planning, which is why we spend 8–14 weeks on discovery, assessment, and design before writing a single line of migration code. ### Should we choose Azure, AWS, or the ERP vendor's own cloud? For lift-and-shift or re-platforming, you are choosing between Azure, AWS, and to a lesser extent GCP for your infrastructure. Azure has the strongest integration with Microsoft-stack ERPs (Dynamics, systems running on SQL Server and Windows) and currently offers the most mature managed services for enterprise applications. AWS has the broadest service catalog and is often cheaper at higher compute volumes. GCP is rarely the first choice for ERP hosting but is viable if your organization is already invested in the Google ecosystem. For re-implementation, the cloud platform choice is usually made for you by the ERP vendor. Epicor Kinetic runs on Azure. Infor CloudSuite runs on AWS. Dynamics 365 runs on Azure. NetSuite runs on Oracle Cloud Infrastructure. Sage Intacct runs on its own managed cloud. The infrastructure decision matters less than the ERP platform decision because the ERP vendor manages the infrastructure layer in a SaaS model. Where it does matter is for integrations: if the rest of your technology stack is already on Azure (your data warehouse, your Power BI environment, your Active Directory), running your ERP on Azure simplifies networking, authentication, and data movement. The vendor lock-in concern is real but often overstated — you are already locked into your ERP vendor. The infrastructure layer is the easier thing to change later. ### What are the ongoing costs after migration compared to on-premise? On-premise ERP total cost of ownership includes hardware (server refresh every 4–5 years at $50K–$150K), software licensing (perpetual licenses plus 18–22% annual maintenance fees), infrastructure (power, cooling, rack space, network equipment, backup infrastructure, DR site), and IT labor (1–2 FTEs dedicated to ERP infrastructure at $80K–$130K loaded cost each). For a mid-market manufacturer with 100–300 users, total on-premise annual run rate is typically $200K–$500K. Cloud ERP ongoing costs include subscription licensing ($150–$300 per user per month for manufacturing-specific platforms, so $180K–$1.08M annually for 100–300 users), cloud infrastructure (typically included in SaaS subscriptions; $2K–$8K/month for IaaS if lift-and-shift), and support/maintenance (included in subscription for SaaS; $2K–$8K/month for managed services if IaaS). The subscription model costs more annually than perpetual license maintenance fees. Where cloud saves money is the elimination of hardware refresh cycles, the reduction of IT staff dedicated to infrastructure, and the disaster recovery and high availability that is built into the subscription rather than requiring separate infrastructure investment. The crossover point — where cloud becomes cheaper than on-premise on a cumulative basis — is typically 3–5 years for re-implementations and may never arrive for lift-and-shift (because you are still paying IaaS costs plus the old maintenance fees). Every migration business case should model a 5-year TCO comparison with realistic numbers, not the vendor's optimistic projections. --- **Canonical URL**: https://freedomdev.com/solutions/on-premise-to-cloud-erp _Last updated: 2026-05-13_