web
You’re offline. This is a read only version of the page.
close
Skip to main content

Announcements

No record found.

News and Announcements icon
Community site session details

Community site session details

Session Id :
Small and medium business | Business Central, N...
Suggested Answer

Merging multiple Business Central extensions into one – how to handle existing data?

(6) ShareShare
ReportReport
Posted on by 20

Hello,

I have a situation in Business Central where I need some guidance

Currently, I have 4 AL projects:

Project A → depends on Projects B, C, and D

Projects B, C, D → contain their own tables, pages, and other objects

I decided to merge everything into a single extension (i made a copy of Project A).

What I already did:

I merged all objects (tables, pages, codeunits, etc.) from B, C, and D into the copy of project A source code.

My question is:

Since I am not changing Business Central version (I’m on the same version), what is the correct way to bring existing data from Projects B, C, D into the new merged Project A?

🙏 Thanks in advance for your time and support. I really appreciate any guidance or best practices you can share.
 
I have the same question (0)
  • Suggested answer
    Pallavi Phade Profile Picture
    5,420 Super User 2026 Season 1 on at
    Namaste, 
     

    This exercise should be considered from an application customization perspective. Since Extension A and A-Copy will have different extension IDs and object IDs, the copied extension will not retain data from other extensions, which creates a risk of data loss.

    Tips

    Migrate the data carefully, keeping in mind that table IDs may differ. 

    Merge the extensions, ensuring there are no dependencies, and confirm that all relevant scripts are published successfully. 

    Verify the data thoroughly. Re-verify the customizations to avoid discrepancies

     
    Other than the above considerations, I am fine with this approach.
     
    IF you feel this answer is helpful , please verify the answer 
     
    Regards 
    Pallavi Phade
  • CU10061055-0 Profile Picture
    20 on at

    Thanks a lot, Pallavi 🙏 I really appreciate your answer and the cautions you shared.

    Since this is actually my first time doing a data upgrade in Business Central, I was hoping to get some more detailed steps (or even direct articles/resources) to guide me through the process.

    If anyone has a step-by-step example or could point me to the right Microsoft documentation/blogs for a first-timer, it would help me a lot.
    Thanks again for the support, really appreciate the guidance from the community!



     
  • Suggested answer
    Mohana Yadav Profile Picture
    61,204 Super User 2026 Season 1 on at
  • Suggested answer
    Teddy Herryanto (That NAV Guy) Profile Picture
    14,302 Super User 2026 Season 1 on at
    Let's call the new app: Project E.
     
    Project E is a combination of A + B + C + D.
     
    Create Project F which has dependency on A, B, C, D, E.
     
    Use Project F to transfer all data from A, B, C, D to E.
     
    Once done, remove Project A, B, C, D and F.
     
    Now you only have Project E with all the data migrated from the previous apps.
  • Gerardo Rentería García Profile Picture
    25,555 Most Valuable Professional on at

    Hi, good day
    I hope this can help you, and give you some hints.

    Migrating Tables and Fields Between Extensions - Business Central | Microsoft Learn

    Best Regards
    Gerardo

  • Suggested answer
    YUN ZHU Profile Picture
    99,086 Super User 2026 Season 1 on at
    If your program is AppSource Apps, you can transfer it directly using the following method.
    Otherwise, create an intermediate table, transfer the data from all apps first, and then transfer it to the final merged app.
     
    Hope this helps.
    Thanks
    ZHU
  • Suggested answer
    Nimsara Jayathilaka. Profile Picture
    4,950 Super User 2026 Season 1 on at
    When you are merging multiple AL projects into a single extension in Business Central, a special area of challenge is to retain and migrate any existing data from the original projects, since the new merged extension will have a new extension ID and possibly different object IDs. While the application code does merge, the data does not pop as the Business Central system considers extensions as separate entities.

    The best practice is to provide careful consideration to your data migration approach. You will mostly likely want to consider creating implementation scripts or upgrade codeunits with the merged extension to map and migrate the data from the original tables of projects B, C
     
  • Suggested answer
    Rishabh Kanaskar Profile Picture
    6,219 Super User 2026 Season 1 on at
    You Mentioned that you’re staying on the same Business Central version (no platform upgrade involved), you can do this safely, but you must handle it carefully so you don’t lose data during uninstall/install.

    Use Data Upgrade and Schema Sync

    1. Keep Object IDs & Names the Same

    > The most important thing is to preserve the object IDs (tables, fields, pages, enums, etc.) when you move them from Projects B, C, D into Project A.

    > This allows Business Central to match existing data to the new objects during schema synchronization.

    > If you change object IDs or table names, BC will treat them as new tables → resulting in empty tables.

     

    2. Unpublish Old Extensions in a Controlled Way

    Take a backup of your database before you begin.

    Use Unpublish -DoNotSaveData only if you are ready to delete data, in your case, you want to preserve data, so you should uninstall with data retained.

     

    3. Publish & Install the New Merged Extension

    > Build your merged Project A (with all objects from B, C, D).

    > Publish the new extension to your environment.

    > During installation, BC will do a schema sync:

    1. If IDs match, existing data will be mapped automatically.
    2. Pages/codeunits will work seamlessly with the retained data.
     
    4. Optional) Use DataUpgrade Codeunit

    > If you made any structural changes (like renaming fields, merging tables, or changing primary keys), you need to:

    • Create a codeunit with Subtype = Upgrade.

    • Implement OnUpgradePerCompany() or OnUpgradePerDatabase() to migrate or transform data.

     

    5.Test in Sandbox First

     

    6. Things to Avoid

    > Don’t change object IDs during merge (unless you’re ready to write upgrade code to migrate data).

    > Don’t uninstall with -DoNotSaveData:$true — it will drop SQL tables and you’ll lose data.

    > Don’t forget to handle permissions — merged extension should include permissions from all four projects.


       
  • Suggested answer
    Sumit Singh Profile Picture
    11,757 Super User 2026 Season 1 on at
    Hi,

    When you merge multiple AL apps into one, you have to plan how the table ownership and data move. The right path depends on your BC version and whether your extensions are AppSource/on‑prem vs PTE.

    First, identify your scenario

    • BC 25 (2025 wave 1) + AppSource/on‑prem\ Use the built‑in “Move tables and fields between extensions” feature (MovedFrom/MovedTo). The platform will transfer table/field ownership and data during sync/upgrade. (Not supported for PTE as of wave 1.)
    • PTE or older BC versions\ Use a controlled data‑migration approach (upgrade codeunits) or an adopt‑same‑IDs approach (uninstall without deleting data, then take over with identical object IDs).

    Recommended patterns (choose one)

    A) Platform move (best if eligible: BC 25 AppSource/on‑prem)

    1. In source apps (B/C/D) set MovedTo = <AppID of merged A> on each table/field you’re moving.
    2. In merged A define identical tables/fields and set MovedFrom = <AppID of B/C/D>.
    3. Publish/sync/upgrade in the documented order; the platform transfers ownership + data.\ (Irreversible once completed; plan carefully.)

    B) Copy‑then‑deprecate (works everywhere; safest for PTE/older)

    1. Keep B/C/D installed. In merged A, create destination tables/fields (new IDs).
    2. Add an Upgrade codeunit in A (SubType=Upgrade) and copy data in OnUpgradePerCompany.
    3. codeunit 70000 "Merge Upgrade"
    4. {
    5.     Subtype = Upgrade;
    6.     trigger OnUpgradePerCompany()
    7.     var
    8.         SrcB: Record "My B Table";
    9.         DstA: Record "My B Table (A)";
    10.     begin
    11.         if SrcB.FindSet() then
    12.             repeat
    13.                 DstA.Init();
    14.                 DstA.TransferFields(SrcB, true);
    15.                 DstA.Insert(true);
    16.             until SrcB.Next() = 0;
    17.     end;
    18. }
    Run data upgrade, validate, then uninstall B/C/D and finally delete orphaned data when ready.

    C) Adopt same IDs (quick, but test thoroughly)

    1. In merged A, keep the same table/field IDs and schema that existed in B/C/D.
    2. Uninstall B/C/D without deleting data (data is preserved).
    3. Publish/sync merged A; it attaches to the existing data schema.
    4. After go‑live, Delete Orphaned Extension Data for the old apps when confident.\ (Avoid “clean” sync during uninstall, or you will drop the data.)

    Practical tips & gotchas

    • Keep schemas identical (field IDs, types, lengths, keys) when adopting data to avoid sync errors.
    • Run in a sandbox first; large moves should be done off‑hours.
    • For tableextension fields specifically, platform moves (BC 25 AppSource/on‑prem) handle them; otherwise use upgrade code to copy values to new fields, then obsolete old ones.
    • Use Upgrade Tags to make your upgrade routines idempotent and traceable.

    What I’d do in your case

    • If you’re PTE or not on BC 25 wave 1 → go with B) Copy‑then‑deprecate (most predictable, no reliance on platform move).
    • If you’re BC 25 AppSource/on‑prem and want minimal code → A) Platform move.

    Answer created with the help of Co-Pilot.
    Mark true, “Does this answer your question” if it helps.

Under review

Thank you for your reply! To ensure a great experience for everyone, your content is awaiting approval by our Community Managers. Please check back later.

Helpful resources

Quick Links

Introducing the 2026 Season 1 community Super Users

Congratulations to our 2026 Super Stars!

Meet the Microsoft Dynamics 365 Contact Center Champions

We are thrilled to have these Champions in our Community!

Congratulations to the March Top 10 Community Leaders

These are the community rock stars!

Leaderboard > Small and medium business | Business Central, NAV, RMS

#1
OussamaSabbouh Profile Picture

OussamaSabbouh 2,005 Super User 2026 Season 1

#2
YUN ZHU Profile Picture

YUN ZHU 1,148 Super User 2026 Season 1

#3
Khushbu Rajvi. Profile Picture

Khushbu Rajvi. 557 Super User 2026 Season 1

Last 30 days Overall leaderboard

Featured topics

Product updates

Dynamics 365 release plans