Retiring Dynamics 365 Finance & Operations means preserving agreed historical records and usable access before removing the source application dependency. For this scenario, prioritise legal-entity context, financial dimensions and supporting documents. Compare required reports and documents with source evidence, test permissions and obtain business acceptance before scheduling shutdown.

This guide covers the retirement questions, a mock-data ArchiveHub demonstration and the validation work needed to define a project scope.

The real cost of a "read-only" D365 environment

Cost categories are a discovery checklist, not a guaranteed savings calculation. Verify support status, deployment, shared infrastructure and contract terms for the actual installation.

Keeping Finance & Operations open for reference is a subscription decision, renewed every year:

  • Environment and licence fees. The production environment and the user licences that auditors, tax staff and controllers need to sign in do not stop billing because nobody posts.
  • Mandatory service updates. Microsoft keeps the platform current. A read-only environment still receives updates, and someone still has to check that customisations, ISV solutions and reports survive them.
  • Security and access administration. Security roles, duties and privileges have to be maintained for a shrinking set of occasional users, with access reviews that still have to be signed.
  • Know-how. Reading D365 history means knowing financial dimensions, legal entities and DataAreaId, voucher numbering, the difference between a ledger journal and the general journal entries it posted, and how value models drive fixed asset books. That knowledge leaves with the implementation team.

Scope, versions and evidence

This is an illustrative workflow, not a customer case study. Confirm the source release, deployment, modules, customisations and extraction permissions before using the mappings below. Tables and report labels describe the demonstration catalogue; native-report equivalence has not been independently certified. Use agreed source reports and representative records for acceptance testing.

An archive is not a replacement for every operational feature of the retired ERP. Document required historical tasks, excluded functions and any archive-derived calculations.

Historical data to scope for Dynamics 365 Finance & Operations

ArchiveHub keeps the D365 F&O data model, table by table, under the names a D365 consultant would expect.

General ledger. GeneralJournalEntry and GeneralJournalAccountEntry hold every posted voucher and ledger line. LedgerJournalTable and LedgerJournalTrans keep the journals as entered, SubledgerVoucherGeneralJournalEntry links subledger vouchers to their ledger postings, and TransactionLog keeps the audit trail of who posted what. MainAccount, DimensionAttributeValueCombination and FiscalCalendarPeriod keep the chart of accounts, financial dimension combinations and calendar intact.

Receivables and payables. CustTable, CustTrans, CustTransOpen and CustSettlement; VendTable, VendTrans, VendTransOpen and VendSettlement; the posted invoice journals CustInvoiceJour/CustInvoiceTrans and VendInvoiceJour/VendInvoiceTrans, plus customer packing slips and vendor product receipts.

Orders and products. SalesTable/SalesLine and PurchTable/PurchLine, InventTable and InventTableModule for released products, EcoResProduct for the shared product master.

Tax, bank, assets, projects, budgets. TaxTrans and TaxReportVoucher; BankAccountTrans, BankAccountStatement and BankChequeTable; AssetTable, AssetBook and AssetTrans; ProjTable, ProjCostTrans and ProjBudgetLine; BudgetTransactionHeader and BudgetTransactionLine.

People. DirPartyTable and LogisticsPostalAddress for the global address book; HcmWorker, HcmEmployment, HcmPosition and HcmJob; PayrollPayStatement and PayrollPayStatementLine for pay history.

Fields keep their D365 names with descriptions, and SRSAnalysisEnums comes across too, so a posting type or transaction type can be read as a label rather than an integer. Ad-hoc queries use the same table and field names your developers and report writers used.

Preserve legal-entity context where applicable and distinguish shared master data from company-specific records, so a group that ran several companies in one environment can still filter by company, and every ledger line still carries its DimensionAttributeValueCombination, so department, cost centre and other financial dimensions remain usable for slicing history. Settlements are kept as well: you can still see which payment closed which invoice, and when, for both customers and vendors.

Explore the demonstration

Posted Journals list in ArchiveHub Posted Journals: general journals by legal entity, journal batch number and posting date, as listed in D365. ArchiveHub demonstration using mock data; not a native ERP screen or customer implementation.

Posted Journals detail page Posted Journals detail: one journal with its lines, main accounts and financial dimensions. ArchiveHub demonstration using mock data; not a native ERP screen or customer implementation.

Customer Aging in ArchiveHub Customer Aging: open customer transactions by customer, aged into periods at the archive cut-off. ArchiveHub demonstration using mock data; not a native ERP screen or customer implementation.

Explore the report reference catalogue

These mappings identify intended business workflows, not certified one-for-one equivalents. Confirm availability, source coverage, filters, currencies, dates and calculations for the selected release and implementation.

Finance

  • Fixed Asset Roll Forward: reference workflow: Fixed assets > Inquiries and reports, Fixed asset roll forward report.
  • Fixed Asset Transactions: reference workflow: Fixed assets > Inquiries, Fixed asset transactions (AssetTrans).
  • Audit Trail: reference workflow: the General ledger Audit trail (TransactionLog), who posted what and when.
  • Bank Reconciliation: reference workflow: Cash and bank management bank statements and account reconciliation (BankAccountStatement).
  • Bank Transactions: reference workflow: Cash and bank management Bank transactions (BankAccountTrans).
  • Budget Register Entries: reference workflow: Budgeting Budget register entries (BudgetTransactionHeader, BudgetTransactionLine).
  • Actual vs Budget: reference workflow: Budgeting Actual vs. budget by main account and department financial dimension.
  • Customer Aging: reference workflow: the Credit and collections Customer aging report as of the archive cut-off.
  • Customer Invoice Journal: reference workflow: the Accounts receivable Invoice journal (CustInvoiceJour).
  • Customer Payments: reference workflow: the customer payment journal and settlements (CustSettlement).
  • Customer Transactions: reference workflow: Accounts receivable customer transactions.
  • Fixed Assets: reference workflow: All fixed assets and value models (AssetTable, AssetBook).
  • Posted Journals: reference workflow: General ledger posted general journals (LedgerJournalTable).
  • Main Accounts: reference workflow: Main accounts (chart of accounts).
  • All Projects: reference workflow: Project management and accounting All projects, investment projects with budget (ProjTable, ProjBudget).
  • Posted Project Transactions: reference workflow: Posted project transactions (ProjCostTrans).
  • Ledger to Subledger Reconciliation: reference workflow: the General ledger ledger-to-subledger reconciliation at fiscal year end.
  • Sales Tax Payments: reference workflow: Tax > Inquiries, Sales tax payments (TaxReportVoucher), settle and post sales tax.
  • Posted Sales Tax: reference workflow: Tax > Inquiries, Posted sales tax (TaxTrans).
  • Trial Balance: reference workflow: the Trial balance by legal entity and fiscal period.
  • Vendor Aging: reference workflow: the Accounts payable Vendor aging report as of the archive cut-off.
  • Vendor Invoice Journal: reference workflow: the Accounts payable Invoice journal (VendInvoiceJour) and invoice journal postings.
  • Vendor Payments: reference workflow: the vendor payment journal and settlements (VendSettlement).
  • Vendor Transactions: reference workflow: Accounts payable vendor transactions.
  • Voucher Transactions: reference workflow: General ledger voucher transactions.

Human Resources

  • Pay Statements: reference workflow: Payroll Pay statements (PayrollPayStatement, PayrollPayStatementLine).
  • Workers: reference workflow: Human resources Workers and employment history (HcmWorker, HcmEmployment).

Purchasing

  • All Purchase Orders: reference workflow: Supply Chain All purchase orders.
  • All Vendors: reference workflow: All vendors.

Sales

  • All Customers: reference workflow: All customers.
  • All Sales Orders: reference workflow: Supply Chain All sales orders.

Sales & Purchasing

  • Released Products: reference workflow: Product information management Released products.

Source documents stay attached

Document types below illustrate the intended scope. Include source attachments and external repositories explicitly, and test retrieval and record linkage before decommissioning.

Vendor invoices, customer invoices and purchase orders keep their PDF documents in the archive. So do customer, vendor and worker records, fixed assets, projects and sales tax returns. When someone asks for the document behind a voucher, it opens next to the archived record.

Beyond the reports

Confirm these capabilities, configuration requirements and limits during the demonstration and scope review; the report catalogue alone does not validate them.

  • Ad-hoc query builder across all archived tables, with D365 field names, descriptions and suggested joins (GeneralJournalAccountEntry to MainAccount, CustTrans to CustTable, and so on).
  • Retention rules and purge with approval, per record type, signed off before anything is removed.
  • Legal hold for records under dispute or investigation.
  • Personal-data governance: agree the lawful retention, access and deletion requirements with the responsible privacy and records teams. Product features alone do not establish regulatory compliance.
  • Access controls: define and test permissions for the required companies, records and sensitive fields. Do not assume that system-level roles reproduce the original ERP permissions, particularly for payroll and HR data.
  • OData feeds to Excel, Power BI and SAP Analytics Cloud.

How the decommissioning project runs

  1. Plan and test the supported extraction route. For cloud Finance and Operations, use supported data-entity exports or another approved integration route; do not assume direct access to the production database. Confirm entity coverage, keys, customisations and attachments. For on-premises deployments, agree the database extraction scope separately. See Microsoft BYOD guidance.
  2. Validate row counts per table and tie the balances: customer and vendor subledgers to their summary accounts, the asset roll-forward to the ledger, the trial balance per legal entity and period to D365's own.
  3. Parallel access. Users run their usual inquiries in ArchiveHub while the environment is still available.
  4. Retire after acceptance. Obtain documented sign-off for data reconciliation, document retrieval, user access, retention and legal holds, recovery and remaining integrations. Retire only the approved components; shared infrastructure may still be needed. End or reduce subscriptions, licences and support only where the contract permits. Budget for archive operation and any residual costs.

Stop renewing for read access

If a D365 Finance & Operations environment is being kept only so people can look back, let us show you its ledger, subledgers and documents in ArchiveHub.

Questions about Dynamics 365 Finance & Operations retirement

Can a cloud D365 archive assume direct database access?

No. Agree a supported extraction route for the deployment, such as appropriate data-entity exports. Test entity coverage, references, customisations and attachments before deciding the retirement scope.

What happens to financial dimensions?

Preserve the combinations, descriptions and company context needed to interpret historical postings. Validate archived filters and balances separately for shared data and legal-entity-specific records.

What does this ArchiveHub demonstration prove?

The screenshots illustrate how selected records can be presented using mock data. They do not prove production completeness, customer outcomes or parity with every Dynamics 365 Finance & Operations report. Request a demonstration against your own approved scope and acceptance cases.

Related retirement resources

For the broader project approach, see Legacy application retirement planning. To evaluate how users will find transactions, follow relationships and retrieve documents, explore archived data reporting. These resources complement this Dynamics 365 Finance & Operations-specific scope rather than replace source-system validation.

Evidence and further reading

The report catalogue and screenshots originate from an internal mock-data demonstration. They are not vendor certification or customer implementation evidence.

Use Microsoft supported data-entity export guidance to locate the documentation for the installed release. This is a documentation entry point, not verification of every table or report mapping in this article.

Fixed-price Dynamics 365 Finance & Operations retirement engagement

ArchiveHub offers a fixed-price engagement for Dynamics 365 Finance & Operations retirement and historical data access, based on an agreed scope, deliverables and acceptance criteria. Request a scoped proposal covering your source systems, data, documents, reporting and validation requirements. The proposal should specify included services, exclusions, ongoing platform or hosting charges, and how scope changes will be handled.

Discuss your Dynamics 365 Finance & Operations retirement requirements with ArchiveHub

Microsoft Dynamics 365 Finance & Operations is a trademark of its respective owner. ArchiveHub is not affiliated with or endorsed by Microsoft.