What's New: Moving Tables and Fields Between AppSource Extensions (2025 release wave 1)

Overview

The video explains that the platform capability to move tables and fields between extensions, added in the previous release, is now extended to publishers so they can refactor AppSource extensions. It applies to AppSource extensions targeting runtime 150 and higher, and to on-premise extensions for Business Central version 26.0 and higher. Per-tenant extensions are not supported.

It walks through how a move works: the source extension marks objects with the pending move obsolete state and a MoveTo property, and the destination uses MoveFrom. It then covers the three scenarios (move down, move up, lateral), constraints on fields, propagation of dependencies, how moves happen during sync, and how AppSource validates submissions. It closes with local validation using the AppSource scope analyzer and the performance characteristics of moves.

Key points

• Source extension sets ObsoleteState to pending move plus MoveTo with the destination app ID; the destination uses MoveFrom with the source app ID. Both IDs must match and the schema must stay the same apart from non-breaking changes such as added fields.
• Move down (destination is a dependency of the source) and move up (destination depends on the source) keep the dependency relationship. A lateral move, with no dependency relationship, is a breaking change.
• Set propagate dependencies to true in the monolith version where the moves occur, for downward moves to direct dependencies, so dependent apps keep access to the moved tables. Moving up or laterally is a breaking change.
• Fields can move from a base table to a table extension, or between table extensions on the same base table. Moving from a table extension back to the base table is not supported.
• Moves happen during the sync stage. The source extension must be deployed before the destination. If the source is not published, new tables or fields are created instead of moving.
• Only the declared destination can take over a moved object. AppSource validation checks this, so submit the source extension first unless the destination is a library extension.
• Field moves between extensions rename the column, base-to-extension field moves use AL data transfer, and table moves use a database rename. Local validation uses the AppSource scope analyzer.

Features

AL objects mentioned

As heard in the captions. A name that matches one object page by exact type and name links to it; the others stay as named.

• table “Sales” at 4:05
• table “Inventory” at 4:05
• table “food items” at 15:09
• page “food items” at 15:19
• enum “my enum” at 16:52

Not found in BC28-30: table “Sales”, table “Inventory”, table “food items”, page “food items”, enum “my enum”.

Quotes

• 1:06 “in uh the previous release uh we added the ability in the platform uh for AL developers to move tables and fields between extensions”
• 1:17 “now we also extend that capability to publishers uh to make it much more efficient for them to refactor their apps source extensions”
• 1:17 “Uh that was used in but also only allowed for the base application in uh 2024 release wave uh 1.”
• 1:42 “you can use it for app source extensions uh targeting the runtime from uh version 150 and higher uh you can also use”
• 1:59 “Uh per tenant extensions are not uh supported for this. Uh in in cloud you can use the for sync uh and upgrade code”
• 12:05 “The rule of thumb to ensure success when you are doing a move is that the source extension in a move must be deployed”
• 13:16 “In version two of our monolith app where we are moving them out, we use the obsolution properties to set them as moved.”
• 14:00 “you don’t need to make new extensions to move tables and fields to them. You can use existing extensions as uh destinations as long”
• 14:11 “takeover from a destination extension is blocked if the source extension is moving to a different destination”
• 17:20 “The process is quite straightforward for submitting to appsource because it handles most of the validation automatically.”
• 19:28 “Submit the source extension first and then the destination. If you are moving down to a library extension, you can put both of them”
• 19:38 “Finally, consider first submitting the source and destination in preview. This way customers can upgrade both of them when both are available”
• 21:05 “If we are moving a field from a table extension to a table extension, then there is no data transfer happening. It is just”
• 21:58 “moving tables and fields is a feature that empowers the L developer to refactor their extensions to modular, more maintainable parts”
• 22:23 “such changes u can still have some downstream impact on uh any uh partner that are building on top of your solution”

Disclaimers in the video

• 1:59 not-in-this-release: Per tenant extensions are not supported for this
• 19:38 coming-later: consider first submitting the source and destination in preview

Presenters (as heard): Peter Boring, Satias Draonis.