Dynamics SL to Business Central: Migration Guide [2026]
Migrating from Dynamics SL to Business Central requires 3–6 months, involves significant data transformation, and typically costs $40K–$200K for mid-market companies, but delivers modern cloud infrastructure and 60% lower total cost of ownership.
Dynamics SL (Solomon IV) reached extended support end-of-life in July 2019, and organizations still running SL face increasing risk: no security patches, vendor lock-in, and an aging architecture that no longer scales with modern business needs. Business Central offers a modernized, cloud-native alternative—but the migration path is complex, requiring careful planning, substantial data transformation, and typically 3–6 months of execution.
This guide covers the business case, technical architecture differences, migration timeline, cost structure, data mapping challenges, and post-go-live optimization strategies for organizations moving from Dynamics SL to Business Central.
Why SL Organizations Are Migrating Now
Dynamics SL was Microsoft's answer to Solomon IV, acquiring the product in 1998 and sunset it in 2019. Three forces are driving migration urgency:
- Security & Compliance Risk: No vendor security patches means vulnerability accumulation. Finance & manufacturing organizations face audit and compliance exposure.
- Cloud Economics: On-premises SL infrastructure (servers, licensing, IT labor) costs 2–3x more annually than Business Central cloud. Over 5 years, cloud pays for the migration.
- Ecosystem Isolation: SL cannot integrate natively with Microsoft 365, Power BI, or modern supply chain tools (JDA, Kinaxis, etc.). Integrations require custom code.
Business Central offers cloud infrastructure, native Office 365 integration, Power BI embedded analytics, and a rapidly growing app marketplace. The ROI typically materializes within 18–24 months.
Technical Architecture: SL vs. Business Central
Understanding the architectural gap is essential to estimating migration scope and complexity.
| Dimension | Dynamics SL | Business Central |
|---|---|---|
| Deployment Model | On-premises; requires SQL Server & Windows servers | Cloud-native (Azure); fully managed by Microsoft |
| Database Structure | Module-based with separate GL, SOP, POP, AR, AP modules | Core tables (Customer, Vendor, Item, General Ledger Entry); apps layer on top |
| Programming Language | dBASE, C/AL (SL-specific dialect) | AL (modern; similar to C#) |
| Customization Model | Direct table modifications; stored procedures | Extension-based; no direct table mods (enforced by platform) |
| Reporting | SL Reports (proprietary); SSRS integration | Power BI embedded; SSRS supported; new report builder |
| Integration | EDI, custom API (COM/ActiveX), ODBC | OData, REST API, Power Automate, Logic Apps |
| User Interface | Menu-driven; role-based screens within modules | Role centers; modern web UI; responsive design |
The implication: SL data and customizations don't map 1:1 to Business Central. Most migrations require data re-engineering and custom code rewriting.
Migration Timeline & Phases
A typical SL-to-BC migration spans 3–6 months. Timeline varies by company size, data complexity, and customization footprint.
Phase 1: Assessment & Planning (Weeks 1–4)
- Inventory SL modules in use (GL, SOP, POP, AR, AP, Payroll?)
- Catalog customizations, integrations, and third-party bolt-ons
- Analyze data volume, age, and quality (orphaned records, duplicate customers)
- Define cutover approach: module-by-module, geography-based, or full cutover
- Estimate data cleansing effort (typically 20–40% of total timeline)
- Build project governance and assign sponsor/steering committee
Phase 2: Design & Build (Weeks 5–12)
- Configure Business Central (CoA, dimensions, customer/vendor segments, item hierarchies)
- Design data mapping specifications (SL AR → BC Customer Ledger Entry, etc.)
- Build ETL pipelines using SSIS, MuleSoft, or dedicated data migration tools
- Re-engineer SL customizations & reports into AL extensions or Power BI
- Build integrations (e.g., existing EDI partners, ECommerce platforms)
- Execute proof-of-concept (POC) data migration on sanitized data
Phase 3: Testing & Refinement (Weeks 13–18)
- User acceptance testing (UAT) on migrated data and new configurations
- Data reconciliation: compare SL GL balances, AR aging, inventory counts vs. BC
- Performance testing: simulate peak order volumes, batch jobs, month-end close
- Integration testing: verify third-party system handshakes (payroll, HR, WMS)
- Identify and resolve data gaps or edge cases
Phase 4: Cutover & Go-Live (Weeks 19–24)
- Final SL data extract (balances as of cutover date)
- Run final ETL migration; reconcile to SL
- Execute parallel month-end close if possible (SL & BC running simultaneously)
- Cut off SL; go live on Business Central
- Enter 2-week hypercare period (extended support, issue triage, data adjustments)
- Decommission SL infrastructure
Faster timelines (12–16 weeks) are possible with pre-built accelerators, but typically sacrifice customization or data depth.
Cost Structure
Migration costs break down across five categories:
| Cost Category | Small ($5M–$50M) | Mid-Market ($50M–$500M) | Large ($500M+) |
|---|---|---|---|
| Implementation Partner (labor) | $20K–$40K | $60K–$120K | $150K–$300K+ |
| Data Migration Tools & ETL | $5K–$15K | $20K–$50K | $50K–$100K+ |
| Testing & QA | $8K–$15K | $20K–$40K | $50K–$100K+ |
| Training & Change Management | $5K–$10K | $15K–$30K | $40K–$80K+ |
| Licensing (first year) | $3K–$8K | $10K–$30K | $50K–$150K+ |
| Total Estimated Range | |||
| LOW—HIGH | $40K–$90K | $125K–$270K | $340K–$730K+ |
These are direct migration costs. Add 15–25% for internal labor (project management, domain experts, change sponsors) and contingency.
Cost drivers:
- Data complexity: Highly customized SL instances with legacy data quality issues cost 30–50% more.
- Customization footprint: Heavy SL customization can add 50–100% to implementation cost.
- Integration scope: Complex third-party integrations (EDI, supply chain, payroll) add $10K–$40K per integration.
- Timeline compression: Shortening timeline from 6 to 4 months adds 20–30% to consulting costs.
However, the post-migration benefit is substantial: Business Central reduces annual operational costs by 30–60% vs. on-premises SL (through cloud infrastructure efficiency, reduced IT labor, and automated processes).
Data Mapping & Transformation Challenges
SL and Business Central use fundamentally different data models. This is the largest technical challenge.
General Ledger & Chart of Accounts
SL stores GL entries in module-specific tables. Business Central consolidates all GL entries into a single G/L Entry table. Mapping is straightforward for balances, but SL's custom GL structures or multi-company setups require re-design in BC.
Accounts Receivable & Customer Ledger
SL stores customer transactions in the Customers and Customer Transactions tables; Business Central uses Customer and Cust. Ledger Entry. The mapping is mostly 1:1, but SL's custom aging buckets or credit limit logic may require re-configuration.
Accounts Payable & Vendor Ledger
Similar to AR: SL vendor transactions must be mapped to BC Vendor Ledger Entry table. Withholding tax or multi-leg approval workflows in SL are rebuilt as BC approval chains.
Inventory & Costing
This is often the highest-risk data mapping challenge. SL uses cost layers and custom costing methods; Business Central supports FIFO, LIFO, average, and standard costing. Organizations often must revalue inventory at cutover using BC's standard costing model, with reconciliation to SL.
Sales & Purchase Orders
SL SOP (Sales Order Processing) and POP (Purchase Order Processing) orders are mapped to BC Sales Header/Lines and Purchase Header/Lines. Open orders are migrated and must be matched to shipments/receipts. Closed/historical orders are often archived rather than migrated.
Intercompany Eliminations
If SL supports multiple companies with intercompany transactions, BC's elimination logic must be reconfigured and tested thoroughly.
Best practice: Conduct a detailed data mapping workshop 4–6 months before cutover. Identify high-risk areas (inventory, multi-company, customizations) early and build migration SQL to test in a pre-production environment.
Dynamics 365 Partner RFI Template & Evaluation Process
Complete RFI template for evaluating Dynamics 365 implementation partners. Includes questionnaire, scoring rubric, and shortlisting criteria.
Read MoreCustomization Re-Engineering
SL customizations are typically built in dBASE (SL Workbench) or C/AL scripting. Business Central's extension model (AL language) is modern but requires a rewrite.
- SL dBASE code: Must be manually converted to AL. This is labor-intensive (typically $10K–$50K per customization).
- SL Reports: SL's proprietary report writer doesn't exist in BC. Reports are rebuilt using SSRS or Power BI. This is often a 20–30% effort multiplier.
- SL Workflows: SL's custom approval workflows are rebuilt as BC approval chains or Power Automate workflows.
- SL Custom Fields: SL's custom table fields are migrated as BC extension fields (no direct schema modification).
Organizations often discover that 20–30% of SL customizations are redundant or add little value. A thorough code audit during assessment phase can reduce re-engineering effort significantly.
Selecting a SL-to-BC Migration Partner
Migration is complex and rarely succeeds with internal teams alone. Look for a partner with:
- SL Experience: Proven track record of 5+ successful SL-to-BC migrations.
- Data Migration Expertise: Dedicated data engineers skilled in ETL tools (SSIS, MuleSoft, custom code).
- Manufacturing/Distribution Focus: If applicable; some partners specialize in inventory-heavy migrations.
- Accelerators: Pre-built templates, data migration utilities, and configuration scripts reduce custom build effort by 20–30%.
- Support Post-Go-Live: 4–8 weeks of hypercare (on-demand support during stabilization).
Request references from at least three completed SL-to-BC migrations similar in size and complexity to your organization.
Post-Migration Success
The first 4–8 weeks after cutover (hypercare period) are critical. Issues to watch:
- Data discrepancies in GL, AR, AP, or inventory balances
- Performance issues in month-end close or heavy batch operations
- User adoption struggles (BC interface differs significantly from SL)
- Third-party system failures (e.g., EDI, payroll integrations)
- Legacy system decommissioning delays
Plan for extended support: assign a dedicated Business Central technical resource, establish an issue tracking process, and conduct daily go-live stand-ups for the first two weeks.
Conclusion
SL-to-BC migration is a 3–6 month, $40K–$200K undertaking for mid-market companies, but the business case is strong: modern cloud infrastructure, 30–60% lower operational costs, and access to a vibrant app ecosystem. The key to success is rigorous planning, data quality assessment, experienced partner selection, and post-go-live stability management. Organizations that start planning today can minimize risk and unlock the benefits of Business Central within 12–18 months.
Frequently Asked Questions
Parallel operations are rarely feasible because of fundamental architecture differences and the cost of maintaining dual systems. Most organizations use a phased cutover approach: migrate Finance first, then Operations, then Payroll—or migrate by geography. Running both systems full-time for months typically costs more than the migration itself.
SL customizations built in dBASE or C/AL code must be re-engineered for AL (Business Central's language). This is often a 20–30% cost factor. Pure configuration is typically preserved, but custom reports, workflows, and integrations require rebuilding.
Conduct a detailed data audit 6 months before migration. Unused or archival SL data is often left in a read-only archive system. Core operational data is mapped to BC tables using ETL tools (e.g., SSIS, MuleSoft). Some data is transformed; some is retired entirely.
Business Central handles $1B+ in annual revenue, though very large enterprises sometimes choose Dynamics 365 Finance & Operations instead. BC's strength is agility and modern cloud infrastructure—better suited for mid-market and growing companies than SL.
BC's user interface is 40–60% different from SL. Plan 3–5 days of training per role, plus 2 weeks of hypercare post-go-live. SL veterans often struggle with BC's "role-based" interface vs. SL's module-based screens.
Most organizations partner with a certified migration partner. A 4–8 person internal team plus 2–3 consultants (12–16 weeks) is typical for a mid-market migration. Doing it entirely in-house is rare and extends the timeline by 50–100%.
Related Reading
Comprehensive Dynamics Migration Planning Guide
Step-by-step planning framework for any legacy Dynamics migration.
How to Choose a Dynamics Migration Partner
Criteria and best practices for selecting the right implementation partner.
Post-Migration Optimization & Stabilization
Managing hypercare, performance tuning, and user adoption after go-live.
2026 Dynamics 365 Business Central Cost & Investment Guide
The definitive guide to Dynamics 365 Business Central implementation costs. Covers licensing ($80–$110/user/mo), implementation ($100K–$500K+ typical range), and ongoing costs. Includes partner billing rate benchmarks, budget planning worksheets, and 10 questions to ask every partner before signing.