# Legacy ERP Migration to Cloud Migrated a 20-year-old on-premise ERP system to a modern cloud architecture with zero downtime, saving $200k/year in infrastructure costs. ## Legacy ERP Migration to Cloud Migrated a 20-year-old on-premise ERP system to a modern cloud architecture with zero downtime, saving $200k/year in infrastructure costs. --- ## Our Process 1. **On-Site Discovery** — Two weeks embedded at InnoTec's facility, documenting every workflow, data flow, and edge case in the legacy system. Our team of three engineers interviewed 22 employees across all departments and documented 147 distinct business processes. We mapped the complete data model, identifying 89 database tables and 312 stored procedures that were still actively used. This discovery phase also included shadowing production supervisors during two complete shift rotations to understand workflows that occurred during second and third shifts. 2. **Architecture Design** — Designed a parallel-sync architecture on Azure that could run alongside the legacy system with real-time data synchronization. The architecture review board at InnoTec approved our proposal, which included detailed diagrams showing data flows, integration points, and failover mechanisms. We selected Azure App Service for hosting, Azure SQL Database with Business Critical tier for the data layer, and Azure Service Bus for message queuing. The design included a comprehensive disaster recovery plan with a Recovery Time Objective (RTO) of 4 hours and Recovery Point Objective (RPO) of 15 minutes. 3. **ETL Pipeline Development** — Built custom ETL pipelines to clean and synchronize 20 years of production data between the old and new systems. Using Azure Data Factory and custom C# services, we processed 4.7 million historical records, cleaning inconsistent data formats and resolving 2,341 orphaned foreign key relationships. The pipelines included comprehensive error handling and retry logic, with detailed logging to Azure Application Insights. We established bi-directional sync mechanisms that could handle up to 500 transactions per minute while maintaining data consistency across both systems. 4. **Frontend Rebuild** — Rebuilt every user-facing screen in React with role-specific dashboards, validated against legacy screens by InnoTec staff. The new interface used Material-UI components customized to match InnoTec's branding, with responsive layouts that worked on devices from 320px mobile screens to 4K desktop monitors. We conducted 12 formal usability testing sessions with actual InnoTec users, iterating on the design based on their feedback. Each major interface component was built in two-week sprints, with InnoTec stakeholders providing sign-off before moving to the next component. 5. **Parallel Testing** — Ran both systems side-by-side for six weeks, comparing outputs and correcting discrepancies before cutover. Every production order, purchase order, and inventory transaction was processed through both systems simultaneously. Our automated testing framework compared 127 critical data points on each transaction, flagging any discrepancies for investigation by our QA team. InnoTec's finance department ran parallel month-end closes in both systems, verifying that all financial reports matched to the penny. This parallel operation gave InnoTec's leadership complete confidence that the new system accurately replicated their business logic. 6. **Zero-Downtime Cutover** — Executed the final switchover on a Friday evening. By Monday morning, the entire company was running on the new platform. The cutover runbook contained 47 specific steps, each with assigned owners, success criteria, and rollback procedures. Our team of six engineers monitored the cutover in real-time from FreedomDev's office, with two InnoTec IT staff on-site at their facility. We established a war room with a video conference bridge and used a shared dashboard to track cutover progress. The entire process took 2 hours and 18 minutes from start to final verification, completing 43 minutes ahead of our planned schedule. --- ## About InnoTec Manufacturing InnoTec Manufacturing is a precision component manufacturer based in Zeeland, Michigan, serving the automotive, aerospace, and industrial equipment sectors. Founded in 1997, the company started as a small machine shop with eight employees and has grown to a 115-person operation spanning two facilities totaling 87,000 square feet. They specialize in high-tolerance machining and complex assembly operations, with particular expertise in components that require multiple manufacturing processes and strict quality certifications. The company experienced significant growth between 2015 and 2022, expanding their customer base from primarily regional manufacturers to include Tier 1 suppliers for major automotive OEMs. This growth trajectory brought revenue from $8.2 million in 2015 to $23.7 million in 2022, with projections to reach $32 million by 2025. Their competitive advantage comes from their ability to handle complex, low-to-medium volume orders that require both precision machining and value-added assembly — a combination that larger manufacturers find unprofitable and smaller shops lack the capacity to handle. InnoTec's customer base is demanding. Automotive suppliers expect just-in-time delivery with strict quality requirements and comprehensive traceability. Aerospace customers require AS9100 certification and lot-level tracking through the entire manufacturing process. The company maintains certifications including ISO 9001:2015, AS9100D, and ITAR registration for defense-related work. These certifications require rigorous documentation and traceability — capabilities that their aging ERP system was struggling to support as volume increased. The leadership team at InnoTec understood that their manufacturing expertise was their core competency, not software development. CEO Mark Vandenberg and COO Jennifer Hartmann had both come from engineering backgrounds and were comfortable with technology, but they recognized that their IT department of three people didn't have the expertise to undertake a migration of this complexity. They had attempted to hire a senior software architect in 2021 but struggled to find qualified candidates willing to relocate to West Michigan for the salary they could offer. InnoTec chose FreedomDev after a competitive evaluation process that included two other custom development firms and three ERP implementation consultants. What differentiated FreedomDev was our willingness to invest time understanding their manufacturing processes before proposing a solution. During the initial consultation, our team spent four hours on-site asking detailed questions about their production workflows, quality processes, and customer requirements. Unlike other firms that pushed standard ERP packages, we acknowledged that InnoTec's custom workflows represented genuine competitive advantages worth preserving. The relationship between InnoTec and FreedomDev was strengthened by geographic proximity and cultural alignment. Both companies are based in West Michigan, share similar values around craftsmanship and long-term thinking, and have leadership teams who prefer direct communication over corporate bureaucracy. InnoTec appreciated that FreedomDev's team could be on-site within 45 minutes when needed, and that our engineers understood the regional manufacturing culture. This cultural fit proved crucial during the intensive discovery and testing phases, where trust and clear communication were essential to success. --- ## The Challenge: A System Too Critical to Replace, Too Outdated to Maintain InnoTec Manufacturing, based in Zeeland, Michigan, had been running on an aging on-premise ERP system for over two decades. The system — originally built on classic ASP and SQL Server 2005 — was the backbone of their operations, managing everything from production scheduling to inventory tracking across multiple facilities. Every purchase order, work order, and shipping manifest flowed through this monolithic application that had grown to over 450,000 lines of legacy code. As the company scaled, the legacy system's limitations became painful. Server maintenance costs exceeded $200,000 annually. Every update required scheduled downtime during production hours. The hardware was nearing end-of-life, and finding developers who could maintain the codebase was increasingly difficult. The three Dell PowerEdge servers running the application were purchased in 2011, and replacement parts had to be sourced from secondary markets when failures occurred. InnoTec had evaluated off-the-shelf ERP replacements, but every solution they tested required fundamentally changing their manufacturing workflow — the very process that gave them a competitive edge. They needed a partner who could modernize the technology without disrupting the business logic that made them successful. Over 18 months, they had demo'd SAP, Oracle NetSuite, and Microsoft Dynamics 365, investing over $85,000 in consultation fees and proof-of-concept implementations that never reached production. The technical debt was staggering. The application used VBScript components that hadn't been updated since 2008. Integration with their CNC machines relied on file-drop mechanisms that monitored network shares every 30 seconds. Database queries lacked proper indexing, causing report generation to take up to 45 minutes during peak production hours. The IT team spent an average of 12 hours per week just keeping the system operational, responding to timeout errors and memory leaks that required daily server restarts. Employee frustration was mounting. Production supervisors couldn't access real-time inventory data from their mobile devices — they had to walk back to desktop terminals running Internet Explorer 8 to check stock levels. The warehouse team maintained parallel spreadsheets because the system's picking interface was too slow to use during high-volume shipping periods. Customer service representatives often gave inaccurate delivery estimates because the system's reporting lag meant they were looking at data that was hours out of date. The urgency reached a critical point when InnoTec won a major contract with a Tier 1 automotive supplier that would increase production volume by 40%. Their existing infrastructure simply couldn't handle the load. A consultant's capacity assessment estimated they would need to add two more physical servers at $80,000 each, plus another SQL Server license at $15,000, just to support the increased transaction volume. Even then, the system's architectural limitations meant response times would continue degrading. The risk of doing nothing was existential. InnoTec's CFO calculated that a single day of system failure during peak production would cost approximately $127,000 in lost revenue and contract penalties. The legacy system had experienced three unplanned outages in the previous year, each lasting 4-8 hours. Microsoft had ended extended support for SQL Server 2005 in 2016, meaning security vulnerabilities were no longer being patched. Their cyber insurance provider was threatening to increase premiums by 35% unless they modernized to a supported platform. InnoTec needed a migration approach that acknowledged a hard truth: this wasn't a system they could simply 'rip and replace.' Twenty years of business logic was embedded in that code — logic that represented hard-won manufacturing expertise and competitive differentiation. Any migration partner would need to understand not just the technology, but the manufacturing domain itself, and have the patience to preserve what made InnoTec successful while modernizing the infrastructure beneath it. --- ## Our Methodology: Manufacturing-First Development FreedomDev's approach to the InnoTec project was rooted in our manufacturing-first development methodology, which recognizes that manufacturing software projects require deep domain understanding alongside technical expertise. We began with the principle that the manufacturing process is the source of truth — not the existing software documentation, which we've learned is often incomplete or outdated. This meant our discovery phase involved significant time on the shop floor, observing actual workflows rather than relying solely on stakeholder interviews or system documentation. The core project team consisted of six FreedomDev professionals with clearly defined roles. Two senior full-stack engineers led the technical implementation, specializing in backend architecture and frontend development respectively. One systems architect with manufacturing ERP experience served as technical lead and primary client liaison. One dedicated QA engineer focused exclusively on test automation and validation. One DevOps engineer handled Azure infrastructure, CI/CD pipelines, and security configuration. Finally, a project manager coordinated across teams, managed the timeline, and facilitated communication. This team composition remained stable throughout the five-month project, providing continuity and accumulated knowledge. We structured the project using two-week sprints with a hybrid approach that combined Agile flexibility with the predictability that manufacturing operations require. Each sprint began with planning sessions involving InnoTec stakeholders to prioritize features and review progress. Daily standups kept the team synchronized, but we intentionally didn't require InnoTec staff to attend — instead, we provided written updates via their preferred channels. Every sprint concluded with a demonstration of working software, deployed to a staging environment where InnoTec team members could interact with new features using their own test data. Communication cadence was carefully calibrated to InnoTec's operational realities. We held formal status meetings every Tuesday morning at 9:00 AM, scheduled specifically because this was after InnoTec's Monday production planning meetings but before their schedule got hectic. Our project manager maintained a shared project dashboard in Azure DevOps where InnoTec stakeholders could check progress anytime. When issues arose requiring immediate attention, we used a dedicated Slack channel with guaranteed response times — critical issues within 2 hours, standard questions within same business day. This communication structure respected that InnoTec's team had full-time operational responsibilities beyond our project. Risk mitigation was embedded throughout our methodology. We maintained a living risk register that identified 23 potential project risks, ranked by probability and impact. The highest-ranked risk — data discrepancies between old and new systems not being caught until after cutover — was addressed through our six-week parallel testing period. We also maintained a comprehensive rollback plan that would allow InnoTec to revert to the legacy system within 4 hours if critical issues emerged after cutover. Every architectural decision was documented with the specific risks it addressed and the trade-offs it involved. Our custom software development approach also emphasized knowledge transfer throughout the project. We didn't want to create a situation where InnoTec was dependent on FreedomDev for every system change. During the final six weeks, we conducted formal training sessions for InnoTec's IT team, covering system architecture, common troubleshooting scenarios, and how to make configuration changes without code modifications. We delivered comprehensive technical documentation including architecture diagrams, API specifications, database schema documentation, and operational runbooks. We also recorded video walkthroughs of key administrative tasks, creating a knowledge base that InnoTec's team could reference long after our engagement ended. --- ## Technical Architecture: Built for Performance and Scale The technical architecture for InnoTec's modernized ERP was designed around three core principles: maintain the existing data model to minimize migration risk, implement cloud-native infrastructure for reliability and scalability, and create clear separation between business logic and data access layers for long-term maintainability. The backend was built in .NET 8 using Clean Architecture principles, with distinct layers for domain models, application services, infrastructure concerns, and API presentation. This layering meant that InnoTec's core business logic was isolated from technical implementation details, making future changes easier and less risky. We chose Azure SQL Database Business Critical tier for the data layer, which provided the IOPS performance needed for InnoTec's transaction volume while offering built-in high availability with 99.995% SLA. The database schema was initially replicated exactly from the legacy SQL Server 2005 structure — including table names, column types, and even some denormalized structures that violated normal form principles. This was a deliberate decision: changing the schema during migration would have multiplied project risk. We documented technical debt items for future optimization but prioritized getting InnoTec onto a stable, modern platform first. Post-migration, we implemented indexed views and columnstore indexes that improved reporting query performance by 4.2x without changing application code. The API layer was built using ASP.NET Core Web API with a RESTful design, exposing 147 endpoints organized by business domain (orders, inventory, production, shipping, purchasing, quality). We implemented comprehensive input validation using FluentValidation, standardized error handling that provided useful messages without exposing sensitive system details, and structured logging to Azure Application Insights that captured request/response details, performance metrics, and business context. Rate limiting was implemented at the API gateway level to prevent any single user or integration from overwhelming the system. All endpoints required JWT-based authentication with claims-based authorization that mapped to InnoTec's organizational roles. The frontend React application used a component-based architecture with a shared design system that ensured consistency across all 47 user interfaces. We implemented Redux Toolkit for state management, React Router for navigation, and React Query for server state management and caching. The application was built as a Progressive Web App (PWA) with service workers that enabled offline capability for certain features — particularly important for warehouse staff who sometimes worked in areas with poor WiFi coverage. The build pipeline used Webpack with code splitting that resulted in initial page loads under 2 seconds on 3G connections and subsequent navigation that felt instant due to aggressive caching strategies. One of the most complex technical challenges was implementing the real-time synchronization between the legacy system and new system during the parallel testing phase. We built custom Change Data Capture (CDC) triggers on the legacy SQL Server that wrote changes to a staging schema. An Azure Function with a SQL trigger polled these staging tables every 3 seconds, transformed the data into the appropriate format, and published messages to Azure Service Bus topics. Subscriber services in the new application consumed these messages and applied the changes to the Azure SQL Database. The reverse flow — changes in the new system being written back to legacy — used a similar pattern. This bidirectional sync handled an average of 127 transactions per minute during peak periods without data loss or duplication. Security considerations were paramount given that InnoTec's ERP contained sensitive customer data, proprietary manufacturing processes, and ITAR-controlled technical data. We implemented defense-in-depth with multiple security layers: Azure Front Door with WAF for DDoS protection and application-level attack prevention, Azure Active Directory for authentication with multi-factor authentication required for administrative roles, role-based access control enforced at both API and database levels, encryption at rest using Transparent Data Encryption with Microsoft-managed keys, encryption in transit using TLS 1.3, and comprehensive audit logging that captured who accessed what data when. We conducted a third-party penetration test before cutover, which found zero critical or high-severity vulnerabilities. The scalability design anticipated InnoTec's growth trajectory. The Azure App Service plan we selected (P2V3 with 2 instances) could handle 5x their current transaction volume without modification. We implemented autoscaling rules that would automatically add instances if CPU sustained over 70% for 10 minutes or if response times exceeded thresholds. The database tier could scale vertically to 80 vCores if needed, and we designed the data model to support horizontal partitioning if InnoTec eventually needed multi-region deployment. Our load testing demonstrated the system could handle 1,200 concurrent users with p95 response times under 500ms — far exceeding InnoTec's current needs but providing confidence that the architecture wouldn't be a bottleneck as they continued growing. The systems integration layer deserves special mention due to its complexity. InnoTec's shop floor equipment included 14 CNC machines from three different manufacturers, two automated assembly systems, a coordinate measuring machine (CMM) for quality inspection, and barcode scanners throughout the warehouse. We implemented Azure IoT Edge devices at each integration point, running containerized services that could translate between proprietary machine protocols and standard MQTT messages. These edge devices maintained local buffering, so temporary internet outages wouldn't halt production — messages would queue locally and sync to Azure once connectivity restored. This hybrid cloud-edge architecture gave InnoTec the benefits of cloud-based analytics and centralized management while maintaining shop floor resilience. --- ## Lessons Learned: What Made This Migration Succeed The single most important factor in this project's success was our willingness to invest deeply in understanding InnoTec's business before writing any code. The two-week discovery phase — which some stakeholders initially questioned as excessive — paid enormous dividends throughout the project. Workflows that seemed irrational from a software perspective made perfect sense when understood in manufacturing context. The workarounds that InnoTec employees had developed weren't signs of poor system design; they were intelligent adaptations to real operational constraints. By documenting these workflows with genuine curiosity rather than judgment, we earned trust with the people who would ultimately determine whether this project succeeded. The parallel-sync architecture was more complex and expensive than a traditional 'migrate and cutover' approach, but it eliminated the single biggest risk in any ERP migration: discovering critical data discrepancies only after going live. Running both systems side-by-side for six weeks cost InnoTec additional licensing and infrastructure expenses, and it required our team to build sophisticated ETL pipelines that would be discarded after cutover. However, this investment bought something invaluable: confidence. When we flipped the switch on that Friday evening, InnoTec's leadership knew with certainty that the new system would process their data correctly. That confidence was worth every dollar of the additional cost. One aspect that proved harder than expected was managing the psychological change for InnoTec's employees. Even though we replicated the legacy system's workflows closely, the new interface looked different enough to trigger anxiety among some long-tenured employees. A warehouse supervisor who had used the legacy system for 14 years initially struggled with the new interface, not because it was poorly designed, but because his muscle memory was calibrated to the old system's quirks. We underestimated how much training and hand-holding would be needed. If we were to do it again, we would start user training earlier and invest more in creating video walkthroughs that employees could reference at their own pace. The technical decision to preserve the legacy database schema initially — even where it was suboptimal — proved wise. Several times during testing, we discovered edge cases where the legacy system's behavior depended on specific schema characteristics: a denormalized column that cached calculated values, a nullable field whose NULL state had business meaning, a varchar field that sometimes contained JSON and sometimes contained comma-delimited values. Had we tried to 'fix' the schema during migration, we would have introduced subtle bugs that might not have surfaced until weeks after cutover. By keeping the schema identical and documenting opportunities for future optimization, we separated the risky work (migration) from the improvement work (optimization) and tackled them sequentially rather than simultaneously. Communication cadence and format mattered more than we initially anticipated. Early in the project, we held daily status meetings with InnoTec stakeholders, assuming that more communication was better. We quickly learned that this was pulling InnoTec's operational leaders away from their primary responsibilities without providing proportional value. When we shifted to weekly structured meetings plus asynchronous updates via shared dashboards and written summaries, satisfaction increased on both sides. The lesson: respect your client's time by being intentional about when you need synchronous attention versus when asynchronous updates suffice. Our ongoing relationship with InnoTec has evolved into a true partnership. We continue to provide support under a retained maintenance agreement, but the nature of our work has shifted from 'building the platform' to 'evolving the platform.' In the 14 months since go-live, we've implemented 23 feature enhancements based on feedback from InnoTec's team — improvements that would have been nearly impossible in the legacy system but are straightforward in the modern architecture. We've also begun discussions about Phase 2: adding advanced analytics, implementing machine learning for predictive maintenance on their CNC equipment, and building customer-facing portals for order tracking. The migration project was successful not just because we delivered the system on time and on budget, but because we built a foundation that enables InnoTec to continue innovating for years to come. For organizations considering similar migrations, our advice is this: Don't underestimate the complexity of understanding your existing system, even if you think you know it well. Budget serious time for discovery. Choose a partner who demonstrates genuine curiosity about your business, not just your technology. Be prepared for the parallel testing phase to reveal uncomfortable truths about data quality and business process inconsistencies that have been lurking in your legacy system. Most importantly, recognize that ERP migration is not a technology project — it's a business transformation project where technology happens to be the primary tool. Success requires leadership commitment, employee engagement, and patience to do it right rather than do it fast. --- ## Results: Immediate ROI with Long-Term Scalability - **$200K**: Annual infrastructure savings - **0**: Hours of migration downtime - **3x**: Faster report generation - **99.97%**: System uptime since launch - **14 months**: ROI achieved in - **67%**: Reduction in IT maintenance hours - **2.4x**: Improvement in order processing speed - **100%**: Mobile accessibility - **94%**: Pages loading in under 2 seconds - **41%**: Reduction in data entry errors - **-78%**: Support tickets related to ERP performance - **5x current volume**: Capacity headroom for growth --- ## Technologies - erp-development - sql-consulting - software-migrations - custom-software-development --- **Canonical URL**: https://freedomdev.com/case-studies/innotec-erp-migration _Last updated: 2026-05-14_