Dynamics SL End of Support 2028: Business Central Migration Guide

Dynamics SL End of Support 2028: Business Central Migration Guide

Microsoft Dynamics SL 2018 — the last version of the project-based ERP formerly known as Solomon — loses extended support on July 11, 2028 (learn.microsoft.com). After that date: no security patches, no bug fixes, no support of any kind. Microsoft recommends Dynamics 365 Business Central as the destination for SL customers (microsoft.com). Business Central online includes a dedicated cloud migration tool for SL (learn.microsoft.com), but that tool has boundaries — especially around the project accounting data that makes SL distinctive.

Moving from Dynamics SL to Business Central requires translating a deeply segmented, on-premise, project-centric SQL database into a cloud-native, dimension-based architecture. The migration is rarely a simple lift-and-shift. Dynamics SL is defined by its Project Controller module and flexible subaccounts. Business Central handles these concepts differently, relying on Dimensions and its modernized Projects module.

This guide covers the exact end-of-support timeline, what the native migration tool actually transfers (and what it skips), the structural change from subaccounts to dimensions, the project accounting gap, SQL extraction techniques, the key SL database schema tables, version prerequisites, the Bridge to Cloud 3 licensing discount, and a realistic planning calendar.

For broader context on Microsoft's on-premise sunset strategy, see The Ultimate 2026 Guide to Dynamics 365 On-Premise End of Life.

When does Dynamics SL support end?

Mainstream support for Dynamics SL 2018 ended on January 9, 2024. Extended support, which includes critical security patches, will officially cease on July 11, 2028 (learn.microsoft.com).

Dynamics SL has only one remaining supported version as of early 2025; once SL 2018 reaches end of life, there will be no more supported versions of Dynamics SL. Older versions — SL 2015, SL 2011, SL 7.0, and SL 6.5 — have already passed their end-of-support dates entirely. SL 2015's extended support ended in January 2025 (learn.microsoft.com).

What does "extended support only" actually mean?

Under Microsoft's Fixed Lifecycle Policy, extended support includes security updates at no additional cost and paid support. Non-security updates stop, and Microsoft does not accept design change or new feature requests (learn.microsoft.com). Microsoft partner Velosio reports that year-end updates are no longer provided, the last mainstream update having shipped in December 2023 (velosio.com).

The software doesn't stop running on July 12, 2028. Perpetual licenses keep working after extended support ends. But running an unpatched, unsupported ERP that handles financial data creates mounting audit, compliance, and security exposure. Without security patches, the underlying SQL Server and Windows Server environments become vulnerable. Without tax updates, payroll and 1099 reporting require manual intervention or third-party workarounds. Every month past the deadline increases risk without any vendor safety net.

Native migration tool vs. custom migration: what transfers and what doesn't

The most critical planning artifact for any SL-to-BC migration is understanding exactly where the native cloud migration tool stops. The table below maps every major data category to its migration status.

Business Central includes a cloud migration tool for Dynamics SL that is useful, but it is designed to move the core of your financial data, not everything in SL (learn.microsoft.com). The tool can be configured globally or per company, lets you switch modules off, migrate master data only, include inactive records, and migrate SL classes as posting groups (learn.microsoft.com). The version 29 additions (the "Snapshot Project Transactions" setting and Cash Manager bank accounts) appear in Microsoft's source code for the 2026 release wave 2, not yet in its published documentation (github.com). Confirm them in a sandbox migration before you plan around them.

When the native tool hits its architectural limits, you need a custom data migration strategy—often requiring a non-Microsoft migration provider—that extracts directly from the SQL database and writes to Business Central via API.

For a deeper look at why native tools often drop history, read Why ERP Migrations Fail at the Data Layer: 9 Core Patterns.

Key Dynamics SL SQL tables for migration

Practitioners working directly with the SL SQL database need to know which tables hold which data. The following schema reference covers core migration-relevant tables in the SL application database.

These table names match the SL tables that Microsoft's own migration code and SL Analysis Tool read (github.com).

Note on Flexkey: SL's subaccount structure is defined by the Flexkey configuration, which specifies the number of segments and the character length of each. The FlexDef table in the SL application database holds one row per field class, with NumberSegments and the lengths SegLength00 to SegLength07. Reading it programmatically before splitting subaccount strings is essential — hardcoding segment lengths from memory produces errors when segment definitions vary across companies. Microsoft's Dynamics SL Analysis Tool runs the same query against the application database (github.com).

-- Extract Flexkey segment definitions for subaccounts
-- Run this against the SL application database
SELECT
    NumberSegments,
    SegLength00, SegLength01, SegLength02, SegLength03,
    SegLength04, SegLength05, SegLength06, SegLength07,
    Descr00, Descr01, Descr02, Descr03
FROM
    FlexDef
WHERE
    FieldClassName = 'SUBACCOUNT';

This query returns the segment count and each segment's character length, which drives the substring splitting logic during subaccount-to-dimension transformation.

Subaccounts to dimensions: the biggest structural change

Dynamics SL subaccount segments are the multi-part codes (department, division, location, project) attached to GL accounts for analytical tracking. Business Central dimensions serve the same purpose but are structurally independent of the account number.

Dynamics SL uses a segmented Chart of Accounts. The Account table defines the natural account, and the SubAcct table defines the subaccount structure. A typical SL setup might look like 5000-10-200, where 5000 is the natural account (Travel), 10 is the department, and 200 is the location. Business Central abandons segmented accounts — a natural account exists independently, and transactions are tagged with Dimension Values.

In SL, users can define up to eight different subaccount segments within their GL. Business Central allows two global dimensions and up to eight shortcut dimensions, and as many dimensions overall as you need (learn.microsoft.com). The Dynamics SL subaccount segments are defined as dimensions in Business Central. The SL Company Migration Configuration asks you to enter a segment for Global Dimension 1 and Global Dimension 2. If your SL subaccount has more than two segments outside of the main segment, the other segments are automatically set up as shortcut dimensions (3–8).

The critical design question: which SL segments become which BC dimensions. In a custom load, map only the segments that add reporting value, and leave out default or "00" placeholder segments that add complexity without reporting benefit.

Flexkey extraction for automated segment splitting

Once Flexkey definitions are retrieved, the subaccount splitting logic can be automated:

-- Extracting base accounts from Dynamics SL
SELECT 
    Acct,
    Descr,
    AcctType,
    Active
FROM 
    Account 
WHERE 
    Active = 1;
 
-- Extracting subaccounts for dimension mapping
SELECT 
    Sub,
    Descr,
    Active
FROM 
    SubAcct
WHERE 
    Active = 1;

Once extracted, the Sub string (e.g., 10200) must be split based on your Flexkey definition. If segment one is two characters (Department) and segment two is three characters (Location), the transformation script slices the string using the segment lengths from FlexDef and maps each slice to the corresponding BC dimension value.

Common failure mode: Teams that hardcode segment lengths without querying FlexDef first encounter silent truncation errors when a company database uses non-standard segment lengths. Always derive lengths from the system table, not from visual inspection of subaccount codes.

This is the same structural pattern that hits Dynamics GP to Business Central migrations — segmented accounts must be redesigned, not just replicated.

Project accounting: the gap most teams underestimate

Dynamics SL is used for project-driven accounting: tracking cost and revenue against projects and tasks, allocating overhead and burden, generating time-and-materials, fixed-price and cost-plus invoices, and reporting job-level margin. It remains prevalent among government contractors, construction companies, and professional service firms.

The cloud migration tool moves project master records. But the transaction history that gives those records meaning — cost layers, billing events, timecard hours, allocation markups — does not become Business Central project ledger entries. Version 29 can copy PJTran history into read-only snapshot tables for lookups. For anything you need to report on or bill from inside Business Central's own project ledger, you extract it separately.

No single Dynamics 365 product reproduces SL's project accounting as a like-for-like map. Business Central's standard project features are simpler than SL's, though specialist apps on AppSource can close functional gaps. Business Central's Projects module (formerly called Jobs) is built on a different architecture from SL's Project Controller.

Business Central API endpoints for project data migration

When loading extracted SL project data into Business Central, the standard API v2.0 covers only part of what you need:

Microsoft notes that you can't extend its standard APIs with extra fields. You copy the AL code for the API and build a custom API instead (learn.microsoft.com).

Rate limits: Business Central online applies OData limits per user: 6,000 requests in a 5-minute sliding window, and at most 100 operations in one $batch request. Exceeding the rate returns HTTP 429 (learn.microsoft.com). Bulk project history loads — particularly PJTRAN extracts that may contain hundreds of thousands of rows — need $batch requests and exponential backoff on 429 responses.

Your options for project transaction data:

1. Custom extraction — pull project transactions from SL's SQL database (PJPROJ, PJPENT, PJTRAN) and load them into Business Central or a data warehouse with the relationships intact.
2. Hosted read-only archive — SL holds years of project cost, billing, and contract history that any successor system will only partially import. Keep SL running in an isolated, hosted environment for historical lookups and audit responses.
3. Data lake archive — copy the SL database to Azure storage such as Azure Data Lake; Azure Data Factory can automate the transfer and feed the data into Power BI for historical reporting.

For a structured framework on what to move versus archive, see What Data Should You Actually Migrate to Your New ERP?

How to extract historical data from Dynamics SL

Dynamics SL runs on Microsoft SQL Server. The most reliable way to extract data is via direct SQL queries against the SL application and system databases.

The transfer format preference is API > JSON > CSV. CSV is the least preferred option because flat files frequently suffer from encoding errors, delimiter collisions (commas inside text fields), and truncated leading zeros — problems that occur specifically in SL contexts because subaccount codes and project IDs often contain leading zeros that spreadsheet applications silently strip.

Extracting Project Data

The PJPROJ table contains the master project header. The PJPENT table contains the project tasks. The PJTRAN table contains individual project transactions — cost lines, timecard entries, expense entries, and allocation records.

-- Extracting active projects and tasks
SELECT 
    p.project,
    p.project_desc,
    p.status_pa,
    p.customer,
    p.contract_type,
    t.pjt_entity,
    t.pjt_entity_desc,
    t.status_pa AS task_status
FROM 
    PJPROJ p
JOIN 
    PJPENT t ON p.project = t.project
WHERE 
    p.status_pa IN ('A', 'P'); -- Active and Plan status projects

-- Extracting project transaction detail from PJTRAN
SELECT
    pt.project,
    pt.pjt_entity,
    pt.acct,
    pt.gl_acct,
    pt.gl_subacct,
    pt.units,
    pt.amount,
    pt.trans_date,
    pt.fiscalno,
    pt.employee,
    pt.vendor_num
FROM
    PJTRAN pt
JOIN
    PJPROJ p ON pt.project = p.project
WHERE
    p.status_pa IN ('A', 'P')
ORDER BY
    pt.project, pt.trans_date;

The project header must be transformed into a JSON payload that matches Business Central's API v2.0 projects endpoint. Tasks, planning lines and project ledger history need a custom API page:

{
  "number": "PRJ-10045",
  "displayName": "Software Implementation"
}

Migrating historical project data means mapping PJTRAN cost and revenue lines into BC's project ledger, then reconciling the project-to-date (PTD) and year-to-date (YTD) totals SL reports. Map revenue recognition history as its own workstream.

Extracting closed AP and AR documents

The native tool migrates open documents as live Business Central transactions. Closed documents reach Business Central only through the optional historical snapshot, as read-only data. Closed AP invoices and their payment application history reside in APDoc, APTran and APAdjust. Closed AR invoices and their cash application history reside in ARDoc, ARTran and ARAdjust. Extracting closed documents means filtering on the OpenDoc flag (1 = open, 0 = closed):

-- Closed AP documents
SELECT 
    APDoc.RefNbr,
    APDoc.VendId,
    APDoc.DocType,
    APDoc.DocDate,
    APDoc.OrigDocAmt,
    APDoc.CuryOrigDocAmt,
    APDoc.Status
FROM 
    APDoc
WHERE 
    APDoc.OpenDoc = 0 -- Closed
    AND APDoc.Rlsed = 1 -- Released
    AND APDoc.DocDate >= '2019-01-01'; -- Adjust historical cutoff as needed

Version and infrastructure prerequisites

The cloud migration tool requires Dynamics SL 2015 or later, plus the Intelligent Cloud Base, Dynamics SL Intelligent Cloud, Dynamics SL History SmartLists, and (for US clients) Dynamics SL Intelligent Cloud US apps installed in the BC tenant. The assisted setup is supported only for the United States, Canada, the United Kingdom and Australia. Microsoft's own SL 2015 lifecycle note directs customers on older versions toward an SL 2018 upgrade before moving to Business Central (learn.microsoft.com).

Other prerequisites from Microsoft's documentation:

• SQL Server 2016 SP1 or later, compatibility level 130 or higher. A migration from a live system needs a non-developer SQL Server edition; a migration from a restored backup can use SQL Server 2022 developer edition
• Business Central online tenant with at least one user holding SUPER permissions
• Run the Dynamics SL Analysis and Repair tools before migrating — they provide migration options based on your needs and detect potential migration issues based on your SL system structure (learn.microsoft.com)

SL modules not covered by standard migration paths

The native tool and most migration guides focus on core financials and Project Controller. The following SL modules require dedicated assessment:

• Payroll — SL Payroll history (employee master, pay history, tax records) is not in scope for the native cloud migration tool. Options: migrate to a standalone payroll system, archive in SL SQL, or export to a data warehouse.
• Field Service — SL Field Service (service orders, equipment, service contracts) has no direct BC equivalent in the native tool. Separate products such as Dynamics 365 Field Service require their own integration scoping.
• Order Management — SL sales orders, shipments, purchase orders and PO receipts appear in the historical snapshot tables, but active open orders require manual reconfiguration or custom API load.
• Multi-company environments — the native tool supports migrating any or all companies, but inter-company transaction history, consolidated financial data, and shared dimension structures require explicit mapping decisions for each company pair.

Bridge to Cloud 3: the licensing window for SL customers

Bridge to Cloud 3 (BTC3) is Microsoft's cloud migration promotion designed to help customers move from on-premises Dynamics systems to Dynamics 365 cloud solutions by offering financial incentives and transitional support. Eligible customers receive a 30% discount on Dynamics 365 online licenses for three years, with the promotion running from January 1, 2026 to December 31, 2027.

Eligibility requires (gravoc.com):

• A valid perpetual Dynamics license (NAV, GP, SL, etc.) purchased before September 1, 2024
• A current Enhancement Plan (a lapse of 30 days or less is excused)
• No prior participation in Bridge to Cloud 1 or Bridge to Cloud 2

These terms come from a Microsoft partner's summary of the promotion. Confirm your eligibility with your Cloud Solution Provider partner.

BTC3 covers licensing costs only. It does not fund, plan, or execute data migration or the implementation project — those are separate scopes. For a full analysis of BTC3 economics, see Microsoft Bridge to Cloud 3 (BTC3): Is the 30% Discount Worth It?

How long does a Dynamics SL to Business Central migration take?

Two timelines run in parallel during any ERP transition, and conflating them causes planning failures.

The first is the Business Central implementation — redesigning charts of accounts, configuring modules, rebuilding customizations, training users. That is a separate project led by a BC implementation partner. (See ERP Data Migration vs Implementation: What's the Difference? for why separating these matters.)

The second is the data migration — extracting, transforming, loading, and validating data from SL into Business Central. This is the part ClonePartner performs. Most migrations are completed within 1–5 business days, depending on data volume, complexity, and API rate limits. Small datasets under 10,000 records can finish in under 24 hours. In an SL environment, the volume drivers are the depth of GL and PJTRAN history, closed AP/AR documents, and the number of companies.

For large project histories, the bulk load runs during the working days before go-live while your team keeps working in SL. Go-live is a Monday morning: SL is frozen before the working day starts, and a final delta migration of changed records (about 30 minutes) picks up the last timecards and journal entries. Your team then logs in to Business Central.

We recommend starting scoping at least 3–4 months before your internal cutover deadline.

Validating the migrated data

When moving from SL to Business Central, validation requires:

1. Record-count parity: Verify that the count of active projects in PJPROJ matches the count of Projects in BC. Repeat for every migrated entity — customers, vendors, items, dimension values.
2. Financial checksums: Hash or sum the financial values of extracted SL batches (from GLTran) and compare against the posted G/L Entries in BC by period and account. Any discrepancy traces back to a specific batch or transformation step.
3. Referential integrity checks: Ensure every migrated Project Ledger Entry ties back to a valid Dimension Value, Project Task, and G/L Account. Orphaned entries — those referencing deleted or inactive master records — fail silently unless you test for them.
4. Subaccount-to-dimension mapping verification: For a sample of migrated transactions, confirm that the original SL subaccount string (e.g., 10200) correctly split into the expected Dimension Values (Department = 10, Location = 200) using the Flexkey definition.
5. Open balance reconciliation: Total outstanding AR balances in BC must match the sum of DocBal from ARDoc where OpenDoc = 1 in SL, net of any transactions posted after the extraction date.

Because Dynamics SL lacks modern webhooks for real-time change tracking, the final delta migration has to find changed records from SL's own timestamps (such as LUpd_DateTime) rather than from an event feed.

Pre-migration data cleanup checklist

Migrating decades of Dynamics SL data without cleaning it first increases API load times and clutters the new Business Central environment. Before extracting the SQL database, execute these steps in SL:

• Close inactive projects: Update status_pa in PJPROJ to closed for any project with zero WIP and no activity in the last 24 months.
• Purge zero-balance subaccounts: Do not migrate subaccount combinations from SubAcct that have never held a balance — query GLTran to confirm zero lifetime activity before excluding.
• Reconcile WIP: Ensure all Work in Progress is billed or written off before extracting final project balances from PJTRAN.
• Resolve orphaned project transactions: Any PJTRAN row referencing a PJPROJ or PJPENT record that no longer exists in master tables will fail referential integrity checks in BC. Identify and resolve these before extraction.
• Archive legacy GL history: Decide whether you need 15 years of GL detail in Business Central, or if 3 years of full detail plus 12 years of net changes by period is sufficient. Volume decisions affect load time and the size of your Business Central environment.
• Standardize customer and vendor IDs: SL allows free-form IDs with mixed case and special characters. BC has stricter ID validation. Normalize before migrating to avoid load failures.

For a comprehensive breakdown, review the Accounting Data Migration Checklist: The 10-Point Plan.

Planning calendar for SL organizations

From November 2026, this gives you about 20 months of runway. Simpler SL environments — core financials only, no project history, single company — can compress the timeline significantly. Project-heavy firms with a decade or more of PJTRAN history, government contracting compliance requirements, or multi-company structures should not plan to start and finish in 2028.