Skip to main content
Migration & Upgrades

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.

Last updated: March 19, 202612 min read9 sections
Quick Reference
SL End of SupportJuly 2019 (extended support ended)
Typical Migration Timeline3–6 months
Estimated Migration Cost$40K–$200K (mid-market)
Key DifferenceSL module-based; BC uses core tables & app model
Data ComplexityHigh; SL data structures don't map 1:1 to BC
Cloud DeploymentBC is cloud-native; SL was on-premises
Parallel Run RiskTypically not recommended; cutover is standard
ROI Timeline18–24 months through operational efficiency

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 More

Customization 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%.

Previous
Dynamics Migration Planning: Complete Framework [2026]
Next
Post-Migration Optimization & Stabilization [2026]

Related Reading