The Complete Guide to Migrating from Infor Lawson to CloudSuite

If your organization is still running Infor Lawson S3 or Lawson v10, the conversation about migrating to CloudSuite is no longer optional. After 26 years of working with Lawson and its evolution into CloudSuite, I have guided organizations through every variation of this migration. Here is what you actually need to know.

The Infor Lawson to CloudSuite migration is not a simple upgrade. It is a re-implementation. The sooner your leadership team understands that distinction, the better your chances of success. The underlying architecture, hosting model, integration framework, and user experience are fundamentally different. Treating this as a version upgrade is the single most common mistake I see organizations make.

Why Organizations Are Migrating Now

The pressure to move from on-premise Lawson to CloudSuite has been building for years, but several factors have made 2025 and 2026 the tipping point for many organizations:

• End of mainstream support: Infor has been steadily reducing support and investment in on-premise Lawson S3 and v10. Feature development has effectively stopped for on-premise deployments.
• Security and compliance pressure: Maintaining on-premise infrastructure to modern security standards is increasingly expensive, especially in healthcare, education, and public sector environments where regulatory requirements are tightening.
• Talent scarcity: Finding developers and administrators who know Lawson system administration, LPL, and the legacy Lawson tech stack is getting harder every year. The talent pool is shrinking as experienced professionals retire.
• Missing modern capabilities: CloudSuite offers embedded analytics through Birst, a modern user experience through Ming.le, and workflow automation that on-premise Lawson simply cannot match without heavy customization.
• Infrastructure costs: The true cost of maintaining on-premise servers, database licenses, backup systems, and disaster recovery often exceeds CloudSuite subscription costs once fully accounted for.

Lawson v10 vs. CloudSuite: Understanding the Architecture Shift

Before diving into migration strategy, you need to understand what is actually changing. This is not Lawson with a new name. The architecture is fundamentally different:

• Hosting model: On-premise (you manage everything) shifts to AWS-hosted infrastructure managed by Infor. You no longer control the servers, database, or OS layer.
• Application framework: Lawson's traditional forms and LPL-driven logic give way to a modern web-based interface built on the Infor OS platform with Landmark technology.
• Integration layer: Direct database connections, Lawson System Foundation (LSF), and custom middleware are replaced by Infor ION, a message-based integration backbone using BODs (Business Object Documents).
• Reporting: Crystal Reports and custom Lawson reports are replaced by Birst embedded analytics and Infor OS reporting tools.
• Customizations: LPL modifications, custom forms, and direct database procedures do not migrate. They must be re-evaluated, rebuilt using supported extension points, or eliminated.
• Security model: Lawson security classes and roles are replaced by Infor Federation Services (IFS) for identity management and a new security architecture within CloudSuite.

Multi-Tenant vs. Single-Tenant: A Critical Decision

One of the first decisions in your Infor migration planning is the deployment model:

• Multi-tenant CloudSuite is Infor's strategic direction. You share infrastructure with other customers, get automatic updates, and benefit from lower costs. However, you have less control over upgrade timing and very limited ability to extend or customize the platform.
• Single-tenant CloudSuite gives you a dedicated environment with more control over upgrade schedules and slightly more flexibility for extensions. It costs more and still has far less customization freedom than on-premise Lawson.

The Migration Timeline and Phases

A realistic Lawson to CloudSuite migration takes 12 to 24 months depending on your complexity, number of modules, integration landscape, and organizational readiness. Here is how the phases typically break down:

Phase 1: Assessment and Discovery (2-3 Months)

This is where you take an honest inventory of your current state. Catalog every Lawson module in use, every customization, every integration, every report. Document what LPL modifications exist, what custom database objects have been created, and what third-party tools connect to Lawson.

• Complete module inventory (HCM, Financials, Supply Chain, etc.)
• Customization audit with business justification for each modification
• Integration mapping across all connected systems
• Report inventory and usage analysis
• Data quality assessment
• Organizational readiness evaluation

Phase 2: Design and Planning (2-4 Months)

With your assessment complete, you design the target state in CloudSuite. This is where you make critical decisions about which customizations to replicate, which to eliminate, and which business processes to redesign to fit CloudSuite standard functionality.

• Fit-gap analysis against CloudSuite standard capabilities
• Integration architecture design using ION and Infor APIs
• Data migration strategy and mapping
• Security model redesign
• Testing strategy development
• Change management and training plan

Phase 3: Build and Configure (3-6 Months)

Configure CloudSuite to match your design. Build integrations through ION. Develop any approved extensions. Create the data migration programs and begin iterative data migration testing.

Phase 4: Testing (2-4 Months)

Unit testing, integration testing, user acceptance testing, performance testing, and parallel processing. I strongly recommend at least two full cycles of end-to-end testing before go-live. Lawson-to-CloudSuite migrations have too many moving parts to rely on a single testing pass.

Phase 5: Go-Live and Stabilization (1-2 Months)

Cutover execution, final data migration, hypercare support, and issue resolution. Plan for four to six weeks of intensive post-go-live support.

Data Migration: What to Bring and What to Leave Behind

Data migration in a Lawson to CloudSuite project is not a full database copy. It is a strategic decision about what historical data your organization actually needs in the new system. Here is my guidance after dozens of these migrations:

• Always migrate: Active employee records, open POs and requisitions, active vendor and customer masters, current-year financial balances, open AR and AP transactions, active benefit enrollments.
• Consider carefully: Historical financial transactions (how many years?), terminated employee records, closed PO history, historical payroll detail. Most organizations bring 2 to 3 years of history and archive the rest.
• Leave behind: Obsolete custom table data, orphaned records from decommissioned modules, test data that crept into production, data tied to eliminated customizations.

Integration Re-Architecture: The ION Reality

If your Lawson environment has integrations, and every one I have seen does, this is likely the most underestimated part of your CloudSuite migration. Your current integration methods will not work in CloudSuite:

• Direct database connections are gone. CloudSuite does not expose the database layer. Every integration must go through ION or approved APIs.
• Lawson System Foundation (LSF) calls are replaced by ION API and REST API endpoints. The request and response structures are different.
• Flat file integrations can still work through ION File Channel, but the file formats, scheduling, and error handling all change.
• Custom middleware (MuleSoft, BizTalk, custom scripts) needs to be re-pointed to ION endpoints and adapted to the BOD-based messaging model.

Plan to spend 30 to 40 percent of your total project effort on integration re-architecture. I know that sounds high. It is accurate.

Common Migration Pitfalls

After guiding organizations through this migration repeatedly, these are the pitfalls I see most often:

1. Treating it as an upgrade instead of a re-implementation. This mindset leads to underestimating every aspect of the project: timeline, budget, effort, and organizational change required.
2. Customization debt. Organizations with heavy Lawson LPL customizations face painful decisions. Each modification must be evaluated: can CloudSuite handle this natively? Can the business process change? Does it need to be rebuilt as an extension? This analysis alone can take months.
3. Underestimating the reporting transition. Organizations often have hundreds of Lawson reports and Crystal Reports. These do not migrate. Every report needs to be rebuilt in Birst or another reporting tool, and that requires business users to re-validate every output.
4. Ignoring the security model rebuild. Lawson security and CloudSuite security are completely different frameworks. This is not a conversion. It is a redesign that requires careful planning, especially in regulated industries.
5. Insufficient parallel testing. Running Lawson and CloudSuite side-by-side through at least one full payroll cycle, one month-end close, and one quarter-end is essential. Skipping this to save time is a false economy.
6. Change management as an afterthought. The CloudSuite user interface is dramatically different from Lawson. Users who have worked in Lawson for a decade will struggle without proper training and support. Plan for resistance and address it proactively.

Testing Strategy for Lawson-to-CloudSuite

Testing a CloudSuite migration is more complex than a typical ERP implementation because you are validating that the new system produces the same results as a system your organization has relied on for years. My recommended testing approach:

• Data migration validation: Run automated reconciliation between Lawson source data and CloudSuite target data. Compare record counts, financial balances, and key field values.
• Process testing: Execute every core business process end-to-end in CloudSuite. Hire-to-retire for HCM. Procure-to-pay for financials. Every process your organization runs.
• Integration testing: Test every inbound and outbound integration with actual data. Validate that ION workflows trigger correctly and that downstream systems receive the expected data.
• Parallel processing: Run real transactions in both Lawson and CloudSuite simultaneously for at least one full business cycle. Compare results transaction by transaction.
• Performance testing: Simulate peak load scenarios. Month-end close, payroll processing, open enrollment. CloudSuite performance characteristics are different from on-premise Lawson.
• User acceptance testing: Business users, not IT, must validate that the system meets their operational needs. Give them realistic scenarios and time to test thoroughly.

Cost Factors and Budgeting

Budgeting for an Infor Lawson to CloudSuite migration requires accounting for costs that organizations frequently underestimate:

• Implementation consulting: This is the largest cost. Expect $500K to $3M+ depending on scope, module count, and complexity. Do not select a partner based on the lowest bid.
• CloudSuite subscription: Your new ongoing software cost. Factor in the overlap period where you are paying for both Lawson maintenance and CloudSuite subscription during migration.
• Internal staff time: Your subject matter experts will spend 30 to 50 percent of their time on the project during peak phases. Their regular work still needs to get done. Plan for backfill.
• Data migration and cleanup: Often underbudgeted. Cleaning 10 to 20 years of Lawson data is labor-intensive and requires business decisions, not just technical execution.
• Integration rebuilds: Every existing integration needs to be re-architected for ION. If you have 15 to 20 integrations, this is a significant line item.
• Training: Budget for comprehensive end-user training. The CloudSuite interface is different enough from Lawson that even experienced users need structured training.
• Contingency: Carry 15 to 20 percent contingency. I have never seen a Lawson migration come in exactly on budget. The organizations that plan for surprises handle them. The ones that do not end up in crisis mode.

Making Your Migration Successful

After guiding organizations through this exact transition for over two decades, here is what separates successful Lawson to CloudSuite migrations from the ones that struggle:

1. Accept the re-implementation reality. Budget and plan accordingly. This is not a weekend upgrade.
2. Invest in the assessment phase. Thorough discovery prevents surprises later. Every dollar spent on assessment saves five during build and testing.
3. Make customization decisions early. The longer you delay decisions about which Lawson customizations to keep, eliminate, or rebuild, the more risk accumulates.
4. Prioritize integration architecture. Get your ION design right. Test integrations early and often.
5. Start change management on day one. Communicate early, train thoroughly, and support users through the transition.
6. Choose experienced partners. Lawson-to-CloudSuite migration expertise is specific. General ERP consulting experience is not sufficient. You need people who know both environments deeply.
7. Plan for the long game. An 18-month migration timeline is not a failure. It is realistic. Rushing leads to cutting corners in testing and change management, which leads to a painful go-live and a long stabilization period.