As your Business Central solutions evolve, you might need to refactor your extensions—whether it’s to improve modularity, maintainability, or modernize legacy codebases. One tricky scenario you’ll face is moving tables or fields from one extension to another without losing data or breaking references.
In this post, I’ll walk you through a safe and structured approach to move tables and fields between extensions in Business Central, ensuring your data remains intact and your solution stays healthy.
Why Move Tables and Fields Across Extensions?
Here are common reasons why you may want to refactor and shift data entities between extensions:
- Break down monolithic extensions into smaller, purpose-built apps
- Centralize shared tables into a core extension
- Clean up misplaced or obsolete fields
- Ensure the correct extension owns and manages the data
Best Practices for Safe Refactoring
Before you start moving tables or fields between extensions, follow these best practices to minimize risks:
🔒 Never uninstall the source extension directly if it contains data-critical tables or fields.
⚙️ Use the obsoleting and migration techniques provided by AL carefully.
🔁 Leverage TableSync and upgrade codeunits to migrate data safely.
Important Limitations to Keep in Mind
When moving fields between extensions, be aware of these technical constraints:
- 🚫 Fields that are part of the primary table key can’t be moved.
- ✅ The field’s Name and ID must remain the same during the move.
Step-by-Step Approach to Moving Tables and Fields
Obsolete Table/Field in the Source Extension
Mark the table or field as obsolete in the source extension using AL attributes. This alerts users and ensures safe deprecation.
✔ Moving a Table to Another Extension
Source Extension (Before)
Defines the table to be moved:
Destination Extension (After)
Re-defines the same table:
✔ Moving a Field to Another Extension
Source Extension (Before)
Defines the field:
Destination Extension (After)
Re-defines same field
Key Takeaways
- Use obsoleting, TableSync, and Upgrade codeunits together for safe migration.
- Always respect field and table ID/Name consistency.
- Never manually remove data-critical objects without migration logic.
- Always test migrations in sandbox environments first.
Conclusion
Refactoring extensions in Business Central—especially when it involves moving tables or fields—requires a thoughtful and cautious approach. By following the recommended best practices, respecting field and table constraints, and using tools like TableSync and upgrade codeunits, you can ensure a smooth transition without risking data integrity. Remember, every migration should be thoroughly tested in a sandbox before going live. A well-planned refactor not only enhances modularity and maintainability but also ensures your solution is future-ready.
💡 Need help refactoring your Business Central extensions without risking data loss?
Our experts can guide you through clean migrations, upgrade codeunits, and best practices tailored to your solution.
👉 Contact Us for a consultation or explore our Business Central Services to learn more.
