Customer experience | Sales, Customer Insights,...

Experiences with Offloading Historical Fiscal Years to an External Database

(3) Share

Report

Posted on by PJ-07051320-0

110

I'm interested in hearing about your experiences with offloading historical fiscal years from Business Central to an external database in order to keep the production database size under control. I'm currently working with a customer whose Business Central database is growing by almost 1 GB per day. We've already reviewed the standard cleanup options (retention policies, log cleanup, removing obsolete data, etc.), but unfortunately these have only a limited impact on the overall database growth.

We're now exploring whether archiving or offloading closed fiscal years to an external database could be a viable long-term solution.

Additional information

The customer operates with four sales administrations that purchase inventory from two inventory administrations. For each Sales Order, a Prepayment is posted, and two Purchase Orders are created, one for each inventory administration.

The same process applies to the credit flow, where two orders (Purchase order and purchase return order) are also created and sent to the inventory administrations.

Across all four sales administrations, approximately 10,000 Sales Orders are processed each day. All processed orders are subsequently posted as Invoices.

Categories:

Dynamics 365 Customer Insights - Data

I have the same question (0)

All responses (4)

Answers (0)

Sort by

Suggested answer

Teagen Boll 3,414 Super User 2026 Season 1 on at

Like
a
(1)

Report
Copy link

Link copied!

I can't say i'd recommend that as it would be a pretty lengthy and error prone process. I'm not sure how their database is growing 1GB a day, is there simply a large volume of transactions? Or are attachments being used heavily? Is any data being copied across multiple companies?

If this is transactional data then in my past experience i've actually seen a different approach in scenarios where a client has a large amount of transactional data (think about a restaurant chain or retail store with potentially hundreds of thousands or even millions of individual sales in a month). They kept everything outside of BC and only brough in a summary of GL level data/subledger level data on a weekly (or daily) basis.

I'd probably work with a partner to get to the bottom of why data storage is being consumed that fast and then taking an approach to tackle it based off the type of activity causing the size to baloon.

Azure blob storage is also something to consider and i've worked with many clients who went this approach as BC has some limitations on storage space: Store document attachments in external file storage - Business Central | Microsoft Learn

Best,

Teagen Boll

Work: Catapult ERP

Social: LinkedIn

Was this reply helpful? Yes No
Suggested answer

YUN ZHU 102,540 Super User 2026 Season 1 on at

Like
a
(0)

Report
Copy link

Link copied!

You can check the details regarding the data growing at a rate of 1 GB per day on the page below. If it involves attachments, you can use the method described below.

Business Central 2026 release wave 1 (BC28): Storing Document Attachments outside the database (No customization) – See benefits of external storage support for document attachments

https://yzhums.com/69818/

If it is just a matter of table data... I would personally suggest you reconsider your choice of ERP. BC is designed for small and medium-sized enterprises; given your growth rate, you should be using a system like SAP or FO.

Hope this helps.

Thanks.

ZHU

Was this reply helpful? Yes No
Suggested answer

OussamaSabbouh 18,449 Super User 2026 Season 1 on at

Like
a
(1)

Report
Copy link

Link copied!

Hello,

For Business Central SaaS, I would be very careful with the idea of offloading closed fiscal years and deleting the original transactional data from production. That is not really a standard BC pattern, especially for posted ledgers like G/L, Item Ledger, Value Entries, Customer/Vendor Ledger, VAT, FA, etc., because many balances, drilldowns, audits, applications, cost adjustments, and historical reports still depend on those entries. The safer approach is: first identify the real growing tables from Table Information / Admin Center Capacity, then target the cause — often custom log tables, change log, integration staging tables, attachments/media, job queue logs, or very detailed operational entries. For old closed years, Microsoft’s standard option is date compression, but it has conditions and normally applies to old closed entries, not simply “move year X outside BC.” You can export/copy historical data to Azure SQL/Data Lake for reporting, but I would treat that as a reporting archive, not as a replacement for BC’s transactional history. If the growth is really 1 GB/day after cleanup, I would also review custom extensions and integrations before deciding to buy extra capacity or design a custom archive process.

Regards,
Oussama Sabbouh

Was this reply helpful? Yes No
PJ-07051320-0 110 on at

Like
a
(0)

Report
Copy link

Link copied!

Was this reply helpful? Yes No