Production-grade dynamics ax data extraction tool covering AX 2012 R1/R2/R3, AX 2009 and AX 4.0. SQL Server direct extraction, AIF SOAP document services, AOT metadata crawler, DocuRef/DocuValue attachment streaming, change-data-capture deltas, hash-signed audit trail.
Ad-hoc SELECTs miss EDT inheritance, AOT customizations, AIF business logic, Financial Dimension decoding and document attachments. The result is a migration that fails on row 84,000 of an FBDI job, three months in.
Dynamics AX is not a simple SQL Server application. The AOS (Application Object Server) sits between users and the database, applying X++ business logic, enforcing EDT typing, resolving Financial Dimension combinations through DimensionAttributeValueCombination, and stamping changes across the layered customization stack. A naive SELECT against the AX schema sees flat columns — it does not see that the CustAccount field on CustInvoiceJour is an EDT that inherits from CustAccountBase, or that a custom field added in the USR layer is silently overlaid on CustTable, or that a vendor invoice has 47 DocuRef attachments stored in DocuValue.
A purpose-built dynamics ax data extraction tool addresses all of this. Syntra ETL's AX extractor combines SQL Server direct extraction (fast, complete, hash-signed) with optional AIF SOAP extraction (preserves document-class business logic for AxdCustomer/AxdVendor/AxdSalesOrder), AOT metadata crawling (visibility into every X++ object across all 16 layers from SYS through USR), Financial Dimension decoding (translating DimensionAttributeValueCombination into readable dimension-value tuples), and DocuRef/DocuValue attachment streaming (multi-TB document archives extracted in parallel with hash signatures preserved).
Whether you are feeding a dynamics ax to oracle fusion migration, building a long-term AX cloud archive, or just standing up a queryable historical lookup for finance and audit, the same tool produces the same governed output: Parquet-staged structured data plus original document content, partitioned by fiscal year and legal entity (DataAreaId), with the full extract manifest signed for SOX and statutory audit evidence.
Every AX module that finance, supply chain, manufacturing and audit need. No bespoke client development.
LedgerJournalTrans, General Journal Account Entries, VendInvoiceJour, VendTrans, CustInvoiceJour, CustTrans plus all supporting tables. Multi-period extraction with fiscal-year partitioning.
InventTable, InventTrans, InventSum, InventDim, BOMTable, ProdTable, WrkCtrTable. On-hand by item-warehouse-storage-dimension preserved for Fusion Inventory mapping.
SalesTable, SalesLine, PurchTable, PurchLine, MarkupTrans, SalesQuotationTable. Open and closed orders with line-level pricing, charges, trade-agreement applications.
CustTable, CustTrans, VendTable, VendTrans plus the full DirParty and DirPartyTable structure linking parties across legal entities. Duplicate detection and harmonization in the conversion layer.
DimensionAttribute, DimensionAttributeValueCombination, DimensionAttributeValue plus default account rules and account-structure validation rules. Combinations decoded into readable dimension tuples.
Document attachments (invoices, contracts, supporting documentation) extracted with original file content, hash-signed, indexed by DocuRef key for SOX/HGB-compliant retrieval.
A repeatable, throttled, audit-evidence-producing run pattern. From discovery to ongoing delta sync.
SQL Server login provisioned (SELECT-only on configured tables), optional AIF SOAP client registered with scoped service permissions. AOT metadata crawler runs first — enumerates X++ objects, EDTs, Number Sequences, Financial Dimensions, custom fields across all 16 layers.
Legal entity (DataAreaId) selection, fiscal-year range, module selection (GL, AP, AR, inventory, sales, purchase, manufacturing), DocuRef inclusion toggle. Throttle parameters set (default 4 SQL connections, 10 AIF RPS) per off-peak vs on-peak window.
Small-volume dry-run (one fiscal month, one legal entity) executed end-to-end. Output validated: row counts, hash signatures, DocuRef attachment retrieval, EDT typing, Financial Dimension decoding. Issues caught locally before full extraction commits.
Full historical extract executed across configured scope. Throttled per AOS/SQL load. Output staged as Parquet plus DocuValue documents in object storage, partitioned by fiscal year and DataAreaId. Manifest signed per partition with hash chain.
Change-data-capture using RECID + MODIFIEDDATETIME watermarks on key tables. Incremental extracts run daily or hourly through parallel-run and post-cutover. Feeds Fusion deltas or keeps the AX archive current.
Final full extract becomes the immutable archive of record. AOS, SQL Server licence and physical infrastructure decommissioned per the runbook. Archive remains queryable for the statutory retention period (SOX 7yr, HGB 10yr, HMRC 6yr).
The features that separate a production-grade extractor from a SQL script wrapped in a cron job.
Walks all 16 X++ layers, surfaces every customization, every EDT extension, every custom field. No silent overlays. No surprises in the FBDI load.
Polymorphic fields (CustAccount extending CustAccountBase, ItemId extending ItemIdBase) correctly typed in the extract. Downstream Fusion mapping never sees a generic STRING where it should see a typed reference.
DimensionAttributeValueCombination resolved into readable (dim-name, dim-value) tuples in the extract. No need to JOIN three tables every time you want to know what cost-center a journal line posted to.
Multi-TB document archives extracted in parallel with configurable connection pool, hash signatures preserved per file, DocuRef cross-reference key intact, original filenames and content-types preserved.
Every extract run produces signed timestamped manifest, source row count, extracted row count, hash chain per partition. Sufficient evidence for SOX 404 IT-general-controls on data conversion.
Change-data-capture using RECID + MODIFIEDDATETIME watermarks. Initial bulk + ongoing deltas, same engine, same audit trail. Supports both parallel-run and long-term archive-keeping-pace patterns.
A dynamics ax data extraction tool pulls structured data and document attachments out of Microsoft Dynamics AX — typically AX 2012 (R1/R2/R3), AX 2009 or AX 4.0 — via SQL Server direct extraction against the AOS-managed schema and/or AIF (Application Integration Framework) SOAP services. Syntra ETL's AX extractor handles both pathways: SQL extraction for raw schema access (LedgerJournalTrans, SalesTable, PurchTable, InventTable, CustTable, VendTable) and AIF SOAP for cases where document-class business logic (AxdCustomer, AxdVendor, AxdSalesOrder, AxdPurchOrder validation hooks and derived attributes) needs to be preserved. Output is staged as Parquet plus original document attachments from DocuRef/DocuValue, hash-signed, partitioned by fiscal year and legal entity, ready for Fusion FBDI loading or long-term archival.
You can — for a single table. Production AX extraction needs more: throttled extraction respecting AOS resource limits and SQL Server I/O, change-data-capture for ongoing delta sync, EDT (Extended Data Type) inheritance resolution so polymorphic fields are correctly typed, AOT awareness so X++ business logic embedded in classes is not silently bypassed, multi-layer X++ customization visibility (SYS through USR), Financial Dimension combination decoding through DimensionAttributeValueCombination, AIF document-class preservation, and a hash-signed audit trail for SOX/HGB evidence. Building all that with hand-rolled T-SQL is a 6–9 month engineering project. A dynamics ax data extraction tool ships it pre-built.
All major versions in active production use. Dynamics AX 2012 (R1, R2, R3 including R3 CU13) via SQL Server direct and AIF SOAP. Dynamics AX 2009 (SP1, RU8) via SQL Server direct (AIF in AX 2009 is less feature-rich than 2012; SQL is usually preferred). Dynamics AX 4.0 via SQL Server direct against the AX 4.0 schema. Dynamics AX 3.0 via SQL Server direct for the long-tenured installs still running. SQL Server backend versions from SQL 2005 (AX 4.0 era) through SQL 2016 (last supported with AX 2012 R3 CU13) are all covered. Output normalisation makes the downstream Fusion load pipeline version-agnostic — same FBDI emitters work whether the source is AX 2012 or AX 4.0.
No. The Syntra ETL extractor connects as a low-privilege SQL Server login with SELECT-only access to the relevant tables, and optionally as an AIF SOAP client with scoped service permissions on the inbound/outbound document services you elect to use. No AOS restart is required. No AX schema changes. No X++ code deployment. No layer modifications. Live AX production (sales order entry, invoicing, production control, financial posting) continues uninterrupted. Extracts are throttled to a configurable RPS ceiling on the SOAP side and a connection-count ceiling on the SQL side — typical safe defaults are 4 concurrent SQL connections and 10 SOAP RPS, scaling up during off-peak windows.
Yes. AX 2012 introduced shared schema with DataAreaId scoping per legal entity (and DataAreaId is preserved in nearly every transactional table). The extractor enumerates DataAreaId values from the configured AOS, applies legal-entity filters per extract run, and stages output partitioned by DataAreaId so downstream Fusion BU mapping is straightforward. AX 2009 and AX 4.0 use the same DataAreaId pattern. M&A carve-out scenarios where only one legal entity needs to migrate are first-class supported — the extractor isolates that DataAreaId across every table without disturbing the others.
Yes. The AOT (Application Object Tree) metadata crawler walks every X++ object across all 16 layers (SYS, SYP, GLS, GLP, FPK, FPP, SLN, SLP, ISV, ISP, VAR, VAP, CUS, CUP, USR, USP), enumerates Tables and the EDTs (Extended Data Types) underlying their fields, resolves EDT inheritance so polymorphic fields are correctly typed, identifies custom Tables, custom EDTs and custom fields added in the CUS/USR layers, and feeds the inventory into the Fusion target mapping engine. Customers commonly discover several hundred custom fields they had forgotten about — surfaced before they cause a failed Fusion load.
DocuRef (the AX attachment reference table) paired with DocuValue (the actual document storage, either filesystem or DB BLOB) is fully supported. The extractor walks DocuRef for every source record being extracted, retrieves the document content from DocuValue, hash-signs each file, preserves the original filename, content-type and DocuRef cross-reference key, and stages the documents alongside the structured data in cloud object storage. For Fusion-target loads, documents are bound via FBDI attachment metadata. For archive-target loads, documents stay in object storage indexed by the DocuRef key for SOX/HGB-compliant retrieval. Multi-TB DocuValue archives are routine and handled with parallel streaming.
Both. Initial bulk extraction pulls all in-scope data once for the migration cutover. Continuous delta extraction uses change-data-capture watermarks (RECID + MODIFIEDDATETIME on key tables) for incremental sync during parallel-run and post-cutover periods. The same engine supports the long-term archive pattern where AX continues to run for some period after Fusion go-live and incremental deltas keep the archive current. Once AX is decommissioned, the extractor's last job is a final full extract that becomes the immutable, queryable archive of record — see the dynamics ax cloud archive page for that workflow.
We will run a no-cost discovery extract against a non-production AX instance — your version, your legal-entity scope, your customization profile. You see the AOT inventory, the Financial Dimension decoder output and a sample Parquet partition within 5 working days.