TL;DR
QAD Fabric mirroring runs through Open Mirroring, because Microsoft Fabric has no native mirroring source for QAD. An extraction layer reads tables from the Progress OpenEdge database behind QAD. It writes them as Parquet files into a landing zone in OneLake. Fabric then turns those files into Delta tables and keeps them current. Each table needs a stable key, and each change file needs row markers for inserts, updates and deletes. Once the tables land, Power BI can read them in Direct Lake mode with no second copy.
Key Takeaways Fabric does not list QAD as a native mirroring source. QAD Fabric mirroring depends on Open Mirroring with an extraction layer in front of it. The landing zone expects one folder per table, a _metadata.json file with key columns, and data files numbered in a strict 20-digit sequence. Keys decide whether updates and deletes work. Business keys backed by unique indexes are the safe choice, with the QAD domain added where data is split. Updates carry the full row, deletes carry only the key, and a changed key goes in as a delete followed by an insert. New columns flow through on their own. A changed data type stops that table until its folder is rebuilt, so QAD upgrades need a plan. Kanerika delivers QAD Fabric mirroring as a service on its own QAD integration layer. It has already connected more than 200 QAD tables to Fabric for a global manufacturer. Watch on YouTube
Microsoft Fabric Case Study: FoodPharma Cuts Reporting to 90 Minutes
How Kanerika unified six operational systems on Microsoft Fabric for a functional foods manufacturer.
The Monday Morning Numbers Problem Picture the Monday operations review at a plant running QAD ERP . The inventory dashboard on screen was refreshed by a nightly extract at 2 a.m., and the warehouse has been moving stock all morning. When the open-orders total disagrees with what customer service sees in QAD, nobody can settle it until tonight’s batch runs.
Microsoft Fabric keeps analytics close to the source through mirroring, and it does this natively for databases such as SQL Server, Oracle, Snowflake and SAP. QAD, however, runs on a Progress OpenEdge database with no native mirroring connector.
Open Mirroring closes that distance for QAD. Success depends on an extraction layer and a few design decisions that are easy to get wrong.
Does Microsoft Fabric Support QAD Mirroring? Fabric has no native QAD connector for mirroring. Microsoft’s mirroring overview lists sources such as Azure SQL Database, SQL Server, Oracle, Snowflake, Google BigQuery and SAP, and QAD is not among them. The Open Mirroring partner page names 18 partners, and none of them lists QAD or Progress OpenEdge as a source.
So that leaves Open Mirroring itself. It accepts change data from any application that writes files in the format Fabric expects, which is the opening a QAD integration needs. Progress describes QAD as a manufacturing ERP built on Progress OpenEdge , so the extraction layer reads from the OpenEdge database.
What Fabric Handles and What the Team Builds Fabric takes over once files reach the landing zone. Its replication engine applies each change by key, converts the data to Delta Parquet in OneLake and exposes a SQL analytics endpoint for queries.
Everything upstream belongs to the team or its partner.
That means reading QAD tables from OpenEdge, shaping them into Parquet, numbering files in order and recovering cleanly when a run fails.
Where a Mirror Fits Next to QAD A mirrored database is an analytical copy. QAD stays the system of record, keeps its own backups and recovery plan, and nobody writes back to the ERP through Fabric.
This framing helps when the IT director scopes the project. Mirroring changes how fast reports see QAD data and leaves the ERP itself untouched, so the next question is how Open Mirroring actually works.
What Is Open Mirroring in Microsoft Fabric? Open Mirroring is the Fabric feature that lets any application write change data straight into a mirrored database. It extends the same mirroring service Fabric uses for native sources, and it is built on the open Delta Lake table format.
How the Replication Engine Applies Changes A publisher drops Parquet or CSV files into the landing zone, a OneLake folder tied to the mirrored database. The replication engine then reads them in sequence and applies each row change. The result lands as Delta tables that any Fabric workload can query, such as the lakehouse and Power BI.
Microsoft’s Open Mirroring FAQ describes the latency after files land as near real time. The delay a planner actually sees still depends on how often the publisher writes new files.
What Mirroring Costs on a Fabric Capacity Fabric compute used for replication is free and does not consume capacity. Mirroring storage is free up to one terabyte per capacity unit, so an F64 capacity includes 64 TB, according to the same overview page .
Queries through SQL, Power BI or Spark are billed at regular rates, and a paused capacity stops replication. The extraction layer and its hosting, however, sit outside that allowance. Kanerika’s guides to Fabric pricing and capacity sizing cover the rest of the budget.
How the Open Mirroring Landing Zone Works The landing zone is a contract between the publisher and Fabric. Files that follow the landing zone format replicate, and files that break it stall a table, so the rules come before any extraction code.
Table Folders and the Metadata File Each QAD table gets its own folder, and folders can sit inside schema folders named with a .schema suffix. Every table folder also needs a _metadata.json file.
The keyColumns entry in that file is what makes updates and deletes possible. Keys can be added later, but once set they cannot be changed, so key design comes first.
File Naming, Formats and Ordering Data files use 20-digit sequential names such as 00000000000000000001.parquet, and each new file takes the next number. Fabric reads files in that order and rows within a file in the order written, so a missing number blocks later files for that table.
Parquet and delimited text are both accepted, uncompressed or compressed with Snappy, GZIP or ZSTD. Microsoft’s Open Mirroring best practices recommend uploading under a temporary name that starts with an underscore, then renaming the finished file. Published files should never be appended to or overwritten.
Row Markers for Inserts, Updates and Deletes Change files carry a __rowMarker__ column, and it must be the last column. Its value tells Fabric what to do with each row.
Table 1: Open Mirroring Row Markers
Marker value Operation Row not yet in Fabric Row already in Fabric 0 Insert Inserted Inserted again, with no duplicate-key check 1 Update Inserted Updated by key 2 Delete No change Deleted by key 4 Upsert Inserted Updated by key
The insert marker needs care. It skips the duplicate check, so replaying an insert file after a failure can create duplicate rows. For this reason, the metadata file offers an option to treat unmarked rows as upserts.
The initial load can skip the marker entirely, and Fabric treats those rows as inserts. Incremental mode starts the first time a marker appears, which is why readiness matters before the first file goes out.
Check Readiness Before Building the Mirror A short readiness review saves weeks of rework later. Four areas decide whether the build goes smoothly.
QAD version and hosting. Record the QAD edition, the OpenEdge release and where the database runs, because an on-premises database and a vendor-hosted one allow very different extraction access.Extraction access. Agree on the database account, the read path and the windows when extraction may run, with the OpenEdge administrator involved from day one.Fabric capacity and identity. Confirm an active capacity, a workspace and a Microsoft Entra ID identity that can write to the landing zone.Acceptance criteria. Write down the tables in scope, the freshness target, the reconciliation rules and the load the QAD database can tolerate.Teams that want a broader starting point can work through Kanerika’s data integration checklist alongside this list. With those answers in hand, the build itself follows a fixed order.
Checklist
Data Integration Checklist for Enterprise Teams
Kanerika’s enterprise data integration checklist covers connectivity, reliability, security, partner integrations and governance. Use it alongside the readiness checks above before the QAD build starts.
Get the Checklist → How to Mirror QAD Data into Microsoft Fabric, Step by Step The order below matters, because each step depends on the decision before it. Publishing files before keys and types are settled forces a rebuild, since keys cannot change once set.
Step 1: Pick Tables Around One Manufacturing Question Start with a single business question, such as current inventory by site or open sales orders by customer. In QAD that usually means a handful of tables, for example the item master, the sales order header and line tables, and inventory transaction history.
Confirm names and relationships against the actual schema, since customizations add tables and fields. A narrow first scope also keeps reconciliation in step 7 practical.
Step 2: Choose Keys That Hold Up Across Domains Open Mirroring applies updates and deletes by key, so the key must point to one row for the life of the mirror. A business key backed by a unique index is the safe choice. For example, the part number works for items and the order number plus line number for order lines.
Avoid the OpenEdge ROWID. Progress documents that ROWIDs change when a database is dumped and reloaded , and a single dump-and-load would orphan every row in the mirror.
Multi-domain QAD databases need one more check. When the same part number can exist in two domains, the domain field belongs in keyColumns. Microsoft also suggests keeping composite keys under five columns where possible.
Step 3: Map OpenEdge Data Types to Parquet OpenEdge types need deliberate mapping before the first file is written. Five areas need a decision.
Decimals. Set precision and scale explicitly so quantities, costs and prices do not round on the way into Parquet.Dates. Parquet dates need a valid logical and physical type pair, such as DATE stored as INT32. Otherwise, files with mismatched pairs are rejected.Unknown values. The OpenEdge Unknown value (?) behaves like a null, so any column that can hold it must be nullable.Character widths. OpenEdge can store text longer than a field’s declared SQL width. SQL reads then fail with a value-exceeding-max-length error until DBTOOL corrects the width.Array fields. OpenEdge extent fields hold several values in one field, so decide early whether to split them into separate columns.Keep business rules out of this raw layer. Instead, unit conversions and status mappings belong in downstream tables, where they can change without a reload.
Step 4: Create the Mirrored Database and Landing Zone In the Fabric workspace, select Create, choose the Mirrored Database card, name it and select Create, as shown in the Open Mirroring tutorial . The item’s Home page then shows the Landing zone URL, the OneLake path the publisher writes to.
Teams that automate environments can call the Create mirrored database REST API instead. Programmatic writes go through the OneLake ADLS Gen2 API, and Microsoft publishes an Open Mirroring Python SDK that handles table creation and file naming.
Step 5: Publish a Consistent Initial Load The first load writes every in-scope row without row markers, one table folder at a time. Microsoft’s guidance is to create the full landing zone structure and publish the initial files before mirroring starts.
Consistency is the hard part.
QAD keeps changing while the extract runs, so the publisher needs a clear starting point. The first incremental file then picks up exactly where the snapshot ended.
Step 6: Send Changes in Order with Row Markers Each change file carries full rows for updates and only key columns for deletes, with the __rowMarker__ as the final column. Rows must follow the order of the changes in QAD, because Fabric applies them in file order.
The publisher should record its progress only after a file sits under its final name. A crash between writing and renaming then leads to a clean retry of the same file.
Step 7: Start Replication and Reconcile On the Configure mirroring screen, Mirror all data is on by default, or specific tables can be selected. After Mirror database is selected, the Monitor replication view shows each table moving to Running, with a refresh time once the first copy completes.
Then compare Fabric against QAD for the same cut-off point. Row counts per domain and sums of quantities expose mapping and key errors while the scope is small. The next section covers the changes that break mirrors later.
Handling Deleted Records, Key Changes and QAD Upgrades Edge cases tend to surface after go-live, once real business activity reaches the mirror. Three of them deserve a design decision up front.
Deletes Only Reach Fabric When the Publisher Sends Them Open Mirroring never infers a delete. If a sales order line disappears from QAD and no delete row arrives, the mirror keeps the line. As a result, every report built on it inherits the error.
A delete row needs only the key columns plus marker 2. Scheduled reconciliation by domain acts as the backstop that shows when deletes are slipping through.
Key Changes and Transactions Across Tables A changed key value goes in as a delete of the old key followed by an insert with the new one.
Sending an update that carries a new key value leaves the old row behind.
Ordered files per table also stop short of making a QAD transaction atomic across tables. An order header can appear in Fabric briefly before its lines do, so reports that join headers and lines should tolerate a short lag.
QAD Upgrades, Custom Fields and Schema Drift QAD upgrades and customizations change table definitions, and Open Mirroring reacts to each kind of change in its own way. The landing zone format page spells out the rules summarized here.
Table 2: How Open Mirroring Handles Common QAD Changes
QAD change Open Mirroring behavior What to do New custom field added Column is added to the Delta table Include it in the next file and update downstream models Field removed Older rows keep their values and new rows hold nulls Recreate the table folder to drop the column fully Field data type changed Replication stops for that table Drop and recreate the folder, then reload the table Field or table renamed Needs a rebuilt table folder Recreate the folder with initial and incremental data Key value changed on a row Old row remains if sent as an update Send a delete for the old key, then an insert
Plan the data type case before any QAD upgrade. First, a test run of the upgrade against a copy of the mirror shows which tables need a reload. The production cutover then leaves reports current.
Monitoring QAD Fabric Mirroring in Production A mirror that nobody watches drifts out of step with QAD. Monitoring has to cover both the publisher and Fabric, because each one can fail without the other noticing.
Measure Freshness End to End Freshness has several parts. Extraction after a QAD commit, file publishing, Fabric ingestion and semantic model refresh all add up to what a planner sees.
Track each part separately. When a report runs late, the breakdown shows whether the publisher, Fabric or the report itself caused the delay.
Replication Status and Workspace Monitoring The Monitor replication view shows status values such as Running, Running with warning, Failed and Paused. It also lists rows replicated and the last completed time per table, as described in Microsoft’s monitoring guide .
Workspace monitoring also writes operation logs to the MirroredDatabaseTableExecution table. Teams query it with KQL, the language behind Real-Time Intelligence in Fabric , to build dashboards and alerts.
The publisher needs its own monitoring too. Backlog size, failed uploads and the last file number per table are signals Fabric cannot see. Kanerika’s review of data pipeline monitoring tools covers the options.
Reconcile Against QAD on a Schedule A daily job that compares row counts and control totals per table and domain catches drift before users do. Kanerika’s guide to data reconciliation and its data quality framework cover the methods in more depth.
Failed checks should open a ticket with the table, the domain and the size of the difference. That detail turns a vague complaint about wrong numbers into a fix that takes minutes, which leads into security and cost.
Securing Mirrored QAD Data and Planning the Running Cost Two questions come up in every steering meeting once the mirror works. Who can see the data, and what does it cost to run every month?
Rebuild Access Rules in Fabric Copying rows leaves QAD’s application security behind.
Domain and site restrictions that QAD enforces through its menus are absent from the mirrored tables. Workspace roles, endpoint object permissions and row-level rules in semantic models have to rebuild them.
Give the publisher identity write access to the landing zone and nothing more. Report users then read curated tables and models, and Kanerika’s articles on OneLake security and Fabric governance describe the controls.
Costs Outside Free Replication Free replication compute covers only part of the bill. Extraction hosting, connector licenses and network traffic belong in the budget. So do storage above the free allowance and the capacity that queries and Power BI refreshes use.
A pilot on real QAD change volumes produces a better estimate than any generic rate. It also shows how much load extraction puts on the OpenEdge database during working hours.
Can You Build Power BI Reports on QAD Data in Fabric? Power BI can report directly on mirrored QAD tables. Mirrored tables are v-ordered Delta tables, so semantic models can read them in Direct Lake mode, according to Microsoft’s Open Mirroring FAQ.
SQL Analytics Endpoint and Direct Lake Every mirrored database comes with a read-only SQL analytics endpoint. Analysts can write views over QAD tables there, and Kanerika’s walkthrough of Direct Lake semantic models explains how those models stay current without scheduled imports.
Reports Manufacturers Build First Inventory by site and location usually comes first, followed by open orders against promised dates, supplier on-time delivery and production variance against plan. Each of these suffers most from a day-old extract, and Kanerika’s article on business intelligence for manufacturing covers the wider set.
The bigger payoff comes from joining QAD data with shop-floor and maintenance systems in OneLake. A manufacturing data lakehouse built this way answers questions no single system can. The same tables also feed forecasting and AI in ERP use cases, which raises the question of which loading route fits.
Watch on YouTube
Microsoft Fabric Case Study: Order Lead Time Analytics for Manufacturing
Kanerika’s Microsoft Fabric case study on order lead time analytics for a manufacturer.
Open Mirroring vs Other Ways to Load QAD Data into Fabric Open Mirroring is one of several routes into Fabric. The right one depends on how fresh the data must be and how much engineering the team can own. Kanerika’s guide to OneLake shortcuts compares mirroring with shortcuts, copy jobs and pipelines.
ODBC Through Dataflow Gen2 or Pipelines Fabric Data Factory can read OpenEdge over the ODBC connector through an on-premises data gateway, using Dataflow Gen2 or a data pipeline . It is quick to set up for scheduled loads. Each run reloads or filters data, though, and hard deletes are easy to miss without extra logic.
Table 3: QAD Data Loading Options for Microsoft Fabric
Option Freshness Handles deletes Engineering effort Best fit Open Mirroring with an extraction layer Near real time once files land Yes, through delete markers Highest to build, lower to run with a partner Operational reporting that needs current data Dataflow Gen2 or pipeline over ODBC Scheduled Only with extra logic Low Daily or weekly reporting on smaller tables Third-party replication tool Varies by product Varies by product Medium, plus licensing Teams already licensed for a tool with OpenEdge support Flat-file exports from QAD Scheduled Rarely Low at first, high to maintain Short-term or one-off analysis
Batch loads remain a sound choice when a daily refresh meets the need. Open Mirroring earns its extra build effort when planners make stock and order decisions during the day. Kanerika’s comparison of data integration and ETL covers the wider trade-offs.
Build In-House or Work with a QAD Integration Partner Once Open Mirroring is the chosen route, the next decision is who builds and runs the extraction layer. Both paths work, and the answer usually depends on skills already in the team.
What an In-House Build Needs An in-house build needs people who know the QAD schema and OpenEdge administration, plus data engineering skills in Parquet, OneLake APIs and Fabric operations. It also needs an owner for the publisher after go-live, since schema changes and failed runs continue long after launch.
Questions to Settle Before Choosing Who will restart the publisher at 2 a.m. when a file fails? How will QAD upgrades be tested against the mirror before production? Which reconciliation checks prove the data is right, and who signs them off? What freshness target does the business need, measured end to end? A partner shortens the build when these answers are unclear. Kanerika’s data integration services team builds this kind of pipeline on Microsoft Fabric, as part of wider enterprise data integration work.
How Kanerika Delivers QAD Fabric Mirroring Kanerika delivers QAD Fabric mirroring as a service. The work runs on Kanerika’s own QAD integration layer. It reads QAD tables, applies the key and type decisions described above and writes ordered files to the landing zone.
Assess. Review QAD and OpenEdge versions, hosting, table scope and freshness targets, and agree on acceptance criteria.Pilot. Mirror the tables behind one business question, reconcile them against QAD and build the first Power BI model in Direct Lake mode.Scale. Add domains and tables in waves, with upgrade testing and access rules rebuilt in Fabric.Operate. Set up monitoring, schema change handling and reconciliation, with ongoing support terms agreed with each customer.Results on Live QAD Systems Kanerika has run this on live QAD systems for a global manufacturer with QAD across several sites and regions. The client needed current QAD data in Fabric without a custom connection to maintain. The connection brought more than 200 QAD tables into Fabric through Open Mirroring, with each site in its own space and alerts on every run.
Testing on the live systems surfaced seven QAD-specific issues, all fixed before rollout. Reloads produced no duplicate records, and records deleted in QAD were removed in Fabric, according to the QAD Open Mirroring case study .
Case Study
Bringing Live QAD ERP Data into Microsoft Fabric with Open Mirroring
Kanerika connected more than 200 QAD tables to Microsoft Fabric for a global manufacturer, keeping new, changed and deleted records current with alerts on every run.
Read the Case Study → For FoodPharma, a contract manufacturer of functional foods, Kanerika unified six operational systems on Microsoft Fabric. The seven-week project consolidated more than 50 tables and about 1 TB of history. Cross-functional reporting dropped from two business days to about 90 minutes, according to the Microsoft customer story .
Kanerika is a Microsoft Solutions Partner for Data and AI with the Analytics specialization. Manufacturers weighing QAD to Microsoft Fabric options can start with a short assessment of their QAD environment.
Getting QAD Data into Fabric Without the Nightly Wait QAD Fabric mirroring is a solvable integration problem once the division of work is clear. Open Mirroring handles replication, Delta conversion and query access inside Fabric. The extraction layer handles everything upstream, and its design decides whether the mirror can be trusted.
Stable keys, correct types, ordered files and explicit deletes come first, with a tested plan for QAD upgrades close behind. Manufacturers that start with one business question and reconcile early get Power BI reports that match QAD during the working day.
Talk to Kanerika
Planning QAD Fabric Mirroring?
Kanerika reviews your QAD and OpenEdge setup, table scope and freshness targets, then maps a pilot around one business question.
Talk to Kanerika → Frequently Asked Questions
How do you mirror QAD data into Microsoft Fabric? QAD data is mirrored into Microsoft Fabric with Open Mirroring. An extraction layer reads tables from the Progress OpenEdge database behind QAD and writes them as Parquet files into a mirrored database’s landing zone. Each table needs a _metadata.json file with key columns, and change files carry row markers. Fabric then applies the changes and keeps Delta tables current in OneLake.
Does Microsoft Fabric support QAD mirroring? Microsoft Fabric does not offer a native QAD mirroring connector. QAD is absent from Microsoft’s list of native mirroring sources, and none of the 18 partners on the Open Mirroring partner page lists QAD or Progress OpenEdge as a source. Fabric does support QAD data through Open Mirroring, which accepts files from any application that follows the landing zone format.
What is Open Mirroring in Microsoft Fabric? Open Mirroring is a Microsoft Fabric feature that lets any application write change data into a mirrored database. The application drops Parquet or CSV files into a landing zone in OneLake. Fabric’s replication engine applies inserts, updates and deletes by key and stores the result as Delta tables that Power BI, SQL and Spark can query.
What is a mirrored database in Microsoft Fabric? A mirrored database in Microsoft Fabric is a continuously updated copy of source data stored as Delta tables in OneLake. Fabric creates a read-only SQL analytics endpoint for it automatically. Native mirroring covers sources such as SQL Server, Oracle and Snowflake, and Open Mirroring extends the same model to sources like QAD that need their own publisher.
How does the Open Mirroring landing zone work? The landing zone is a OneLake folder tied to a mirrored database. Each table gets a subfolder with a _metadata.json file that declares key columns. Data files use 20-digit sequential names and are processed in order. A __rowMarker__ column marks each row as an insert, update, delete or upsert, and processed files move to a cleanup folder.
Can you build Power BI reports on QAD data in Fabric? Power BI reports can run directly on mirrored QAD data in Fabric. Mirrored tables are v-ordered Delta tables, so semantic models can read them in Direct Lake mode without a scheduled import. Curated views over the raw QAD tables come first, followed by domain and site access rules rebuilt in the semantic model.
How do you connect a Progress OpenEdge database to Microsoft Fabric? Fabric connects to Progress OpenEdge over ODBC through an on-premises data gateway, using Dataflow Gen2 or a data pipeline. The OpenEdge ODBC driver and a DSN are set up on the gateway machine. This route suits scheduled loads. Continuous mirroring with deletes needs Open Mirroring and an extraction layer that publishes change files.
Is Microsoft Fabric mirroring free? Fabric mirroring replication compute is free and does not consume capacity. Mirroring storage is free up to one terabyte per capacity unit, so an F64 capacity includes 64 TB. Queries through SQL, Power BI or Spark are billed at normal rates. For QAD, the extraction layer’s hosting and support are separate costs outside Fabric.
Why do files disappear from the Open Mirroring landing zone? Files disappear because Fabric moves processed files into _ProcessedFiles or _FilesReadyToDelete folders and removes them after seven days. The service keeps the last file in each table folder so the publisher can see which sequence number comes next. Disappearing files are expected behavior and do not mean data was lost.
Why are Open Mirroring changes not updating the mirrored table? Changes fail to apply when key columns are missing, when the __rowMarker__ column is absent or misplaced, or when the 20-digit file sequence breaks. Updates also need the full row, and a changed data type stops replication for that table. The Monitor replication view and workspace monitoring logs show which table failed and why.
How long does the initial replication take in Fabric mirroring? Initial replication time depends on the data volume and the speed of the publisher writing files, according to Microsoft. Once files land in the landing zone, Microsoft describes replication latency as near real time. For QAD, planning the initial load table by table keeps the first sync predictable and easier to reconcile.
What happens to a QAD mirror during a QAD upgrade? A QAD upgrade can change table definitions, and Open Mirroring handles each change differently. New columns flow through automatically. A changed data type stops replication for that table until its folder is recreated and reloaded, and renamed fields or tables also need a rebuilt folder. Testing the upgrade against a copy of the mirror shows which tables need a reload.
Can the OpenEdge ROWID be used as the key for a mirrored QAD table? The OpenEdge ROWID is a poor choice for a mirror key. Progress documents that ROWIDs change when a database is dumped and reloaded, which would leave every mirrored row pointing at the wrong record. A business key backed by a unique index, with the QAD domain included where data is split by domain, holds up better.
