In Short: How Do You Get ArcGIS Data into Fabric?
ArcGIS is the spatial system of record for most organisations doing serious geographic work, and increasingly we are asked to land its data alongside the rest of the analytical estate in Microsoft Fabric. Municipalities, utilities, insurers, mining operations, logistics organisations, and conservation programmes all run on spatial data that has historically lived inside ArcGIS and rarely joined the broader data conversation.
Esri and Microsoft announced an expanded partnership in 2025, and the integration story has changed materially since. ArcGIS GeoAnalytics for Microsoft Fabric is now generally available, ArcGIS Maps for Microsoft Fabric is in public preview, and the older patterns of REST API extraction and Python integration remain valid alongside them. The right architecture depends on whether you are doing spatial analytics inside Fabric, bringing ArcGIS attribute data into a broader analytical model, or both.
This guide walks through the four approaches, when each one fits, and how we build production ArcGIS to Fabric integrations that handle coordinate reference systems correctly and join spatial data to the rest of the estate without trying to make Fabric into a GIS.
What Problem Does ArcGIS to Fabric Solve?
ArcGIS is excellent at the work it was built for and constrained at the work it was not.
For spatial analysis, cartography, geoprocessing, and field operations, ArcGIS Online and ArcGIS Enterprise are the global standard. Inside the ArcGIS environment, the tools, data models, and analytical capabilities are unmatched. The constraint shows up when the spatial data needs to join the rest of the organisation's data. When operational dashboards need to combine ArcGIS layers with ERP financials or CRM customer records, or when the analytical questions cross from spatial into financial, operational, or executive reporting.
A utility wants to combine asset locations from ArcGIS with maintenance costs from the ERP and customer complaints from the CRM to identify infrastructure most at risk. A municipality wants property records from ArcGIS joined to rates revenue from finance and service requests from the operational platform. An insurer wants to combine hazard zone data from ArcGIS with policy data and claims history to model location-based risk. None of these questions stay inside ArcGIS, and replicating the cross-system data inside ArcGIS is the wrong architectural shape.
A proper ArcGIS to Fabric integration moves the cross-system analytical work to Fabric while keeping ArcGIS as the system of record for spatial operations. The two platforms become complementary rather than competing. ArcGIS runs the spatial workflows, Fabric joins the data to the rest of the estate, and the new ArcGIS-in-Fabric capabilities mean spatial analytics can happen directly inside the Fabric environment where appropriate.
What You Need Before You Start
An ArcGIS to Fabric integration has a small set of hard prerequisites.
A clear picture of which ArcGIS Feature Services or layers you actually need. Most organisations using ArcGIS seriously have dozens or hundreds of layers across multiple services. Not all of them carry analytical value outside of ArcGIS. Identifying which layers drive the cross-system analytics, before you start, is the largest factor in how clean the integration ends up.
ArcGIS access credentials with appropriate scope. For ArcGIS Online, this means a user or application credential with read access across the services you want to integrate. For ArcGIS Enterprise, this means access to the portal and potentially to the backing geodatabase if direct database access is the chosen pattern.
A paid Fabric capacity. F2 or higher for evaluation. F4 to F16 for most mid-market production deployments. ArcGIS GeoAnalytics for Microsoft Fabric runs on Spark and is more capacity-intensive than non-spatial workloads, so capacity sizing factors in if you plan to run heavy in-Fabric spatial analytics.
Awareness of your coordinate reference systems. This is the silent killer of GIS integrations. Different ArcGIS layers often use different coordinate reference systems, and naive integrations that ignore projection produce features in the wrong place by hundreds of metres or more. The integration design has to handle CRS consistently from Bronze through Gold.
If any of these are missing, the integration will be slower and more expensive than it should be. Most first-time issues are around scoping (which layers) and projection handling (which CRS is canonical), not Fabric configuration.
The Four Ways to Integrate ArcGIS with Fabric
There are four real integration patterns. The Esri and Microsoft partnership has changed which one is the strategic default for organisations doing spatial analytics in Fabric.
ArcGIS GeoAnalytics for Microsoft Fabric
The strategic default for any organisation wanting to run spatial analytics inside Fabric. Generally available since November 2025, this is a native Spark library that brings ArcGIS's spatial functions directly into Fabric notebooks and Spark Job Definitions, with no separate installation. Spatial joins, buffers, proximity analysis, hotspot detection, and the broader ArcGIS GeoAnalytics function library run natively against OneLake data. For organisations already invested in Fabric and wanting to add spatial capability rather than maintain a separate GIS analytical environment, this is the cleanest path.
ArcGIS REST API with a Metadata-Driven Framework
The universal extraction pattern. A Fabric pipeline calls ArcGIS REST endpoints for Feature Services, paginates through features, decodes the geometry and attribute data, and lands the result into Bronze as Delta tables. Authentication uses ArcGIS tokens or OAuth depending on the deployment. Incremental loads use the EditDate or equivalent field with a watermark per service. This works for both ArcGIS Online and ArcGIS Enterprise, and is the right pattern when you need ArcGIS attribute data joined to other systems in your analytical model rather than analysed spatially inside Fabric.
ArcGIS Python API in Fabric Notebooks
The Pythonic alternative for organisations whose teams already work in the ArcGIS Python ecosystem. The arcgis library, available on PyPI, runs in Fabric Python notebooks and provides programmatic access to ArcGIS Online and ArcGIS Enterprise. Useful for workflows that combine extraction with on-the-fly spatial processing or for teams transitioning from ArcGIS Notebooks to Fabric. The metadata-driven framework wraps this where the volume of layers makes per-layer scripts impractical.
Direct Geodatabase Access
For ArcGIS Enterprise deployments where the geodatabase is backed by a PostgreSQL, Oracle, or SQL Server database that Fabric can reach, direct database access is the fastest extraction path. The trade-off is that you bypass ArcGIS's spatial logic and feature-service abstractions, which means features managed as views or virtual feature services do not come through. Use this where ArcGIS Enterprise sits next to your Fabric environment and direct access is operationally feasible.
ArcGIS Maps for Microsoft Fabric, in public preview, sits alongside these patterns as the visualisation layer rather than as an extraction pattern. For most production integrations, the right architecture combines GeoAnalytics for Microsoft Fabric for spatial analytics inside the platform with REST API or geodatabase extraction for landing attribute data into the broader analytical model.
How to Build a Production Integration
A production ArcGIS to Fabric integration has five components.
Service Metadata Table
A single table that defines every ArcGIS Feature Service or layer being integrated: the service URL or layer reference, the target Bronze table name, the load type (full refresh or incremental), the incremental key (typically EditDate or last_edited_date), the schedule, the canonical coordinate reference system the integration projects to, and any service-specific transformation rules. The metadata table lives in a Fabric Warehouse and is the single source of truth for what the pipeline does. Adding a new layer is a metadata change. Onboarding a new ArcGIS Enterprise environment is a metadata change.
Orchestration Pipeline
A single Fabric Data Pipeline using the ForEach activity, reading the service metadata at the start and iterating across every row. The pipeline calls a parameterised sub-pipeline or notebook for each ArcGIS service. Error handling, logging, observability, and token refresh are centralised.
Bronze Ingestion Notebook
A parameterised Python notebook that handles the actual extraction. It accepts the metadata row, calls the ArcGIS REST endpoint (or the Python API where it is the better fit), paginates through features using the resultOffset and resultRecordCount parameters, decodes the geometry from ArcGIS's JSON format, and writes the result to a Delta table in Bronze. Geometries are preserved in their native CRS at Bronze, with the source CRS captured alongside. For services with attachments (asset photos, inspection documents), the notebook handles the attachment endpoints separately.
Silver Transformation Layer
This is where the spatial-specific work lives. Silver normalises geometries to a canonical coordinate reference system across all layers, typically WGS84 (EPSG:4326) for analytical work or Web Mercator (EPSG:3857) for web-style mapping. Coded value domains are decoded to their display labels. Range domains are validated. Multi-part geometries are handled consistently. Polymorphic feature types are resolved into typed dimensions. Where the ArcGIS GeoAnalytics for Microsoft Fabric library is in use, the Silver transformations call its functions directly for spatial operations rather than hand-rolling them.
Gold Layer
Business-ready, semantic-model-friendly tables designed against the analytical questions the business actually asks. For utilities: asset facts joined to maintenance and incident dimensions. For municipalities: property facts joined to revenue and service-request dimensions. For insurers: location dimensions joined to policy and claim facts. Geometries are preserved as a spatial dimension that Power BI maps, ArcGIS Maps for Microsoft Fabric, or ArcGIS for Power BI can consume directly. The Gold layer is what semantic models bind to through Direct Lake mode.
What Is the Strategic Point Most Organisations Miss?
The most common mistake in ArcGIS to Fabric integrations is trying to recreate ArcGIS inside Fabric.
ArcGIS has decades of spatial sophistication built into it. The geoprocessing tools, the analytical functions, the cartographic capabilities, the integration with field operations and survey workflows are not reproducible inside Fabric, even with ArcGIS GeoAnalytics for Microsoft Fabric making spatial functions natively available. Organisations that approach a Fabric integration as "migrate our GIS to Fabric" end up disappointed, because Fabric is not a GIS and was never designed to be one.
The right framing is the opposite. ArcGIS stays the system of record for spatial workflows. Fabric becomes the analytical layer where spatial data joins the rest of the organisation's data: financial, operational, customer, asset, transactional. The integration carries ArcGIS data into the broader analytical context rather than replacing ArcGIS as the spatial platform.
This framing also clarifies what ArcGIS GeoAnalytics for Microsoft Fabric actually does. It is not a migration tool. It is a spatial function library that lets Fabric data engineers and data scientists run spatial operations on OneLake data without leaving Fabric. The spatial work in Fabric complements rather than replaces the spatial work in ArcGIS.
The other strategic point that organisations underestimate is coordinate reference systems. Naive integrations that pull data without CRS discipline produce maps where features are in the wrong place by anywhere from a few metres to several kilometres. The fix is straightforward but has to be designed into the integration from the start: a canonical CRS at Silver and Gold, with all source geometries projected to that CRS consistently. Skip this and the integration produces analytical outputs that look correct and are quietly wrong by hundreds of metres.
Who Will Get the Most From an ArcGIS to Fabric Integration?
This integration is most relevant for organisations that:
- Run ArcGIS Online or ArcGIS Enterprise as the spatial system of record for operations, assets, properties, or routes
- Need to join spatial data to financial, operational, customer, or asset data that lives in other systems
- Have ArcGIS attribute data that drives analytical or executive reporting beyond what ArcGIS dashboards natively support
- Are building toward a broader Fabric data platform and need spatial data to be one of several governed sources
- Want to run spatial analytics inside the Fabric environment using ArcGIS GeoAnalytics rather than maintaining separate GIS analytical infrastructure
- Operate in sectors where location is operationally central: utilities, municipalities, insurance, mining, logistics, real estate, agriculture, conservation, retail site selection
Organisations using ArcGIS only for occasional mapping or whose spatial data does not need to join the broader analytical estate may be served adequately by ArcGIS dashboards and ArcGIS for Power BI for in-report mapping. The case for a full Fabric integration scales with spatial data volume, cross-system analytical ambition, and operational dependence on location intelligence.
Why Work With Solv Systems on ArcGIS to Fabric?
At Solv Systems, we build ArcGIS to Microsoft Fabric integrations that handle coordinate reference systems correctly, leverage the native ArcGIS-in-Fabric capabilities where appropriate, and join spatial data to the rest of the analytical estate without trying to make Fabric into a GIS.
Geospatial-aware architecture. We design integrations that respect CRS discipline, decode ArcGIS domain values correctly, handle attachments and multi-part geometries consistently, and treat spatial dimensions as first-class members of the Gold layer. Our experience includes ecological and environmental baseline data pipelines, where spatial precision and CRS discipline are operational requirements.
ArcGIS GeoAnalytics for Microsoft Fabric native. We use the native GeoAnalytics for Microsoft Fabric library for in-Fabric spatial analytics where it fits, rather than hand-rolling spatial logic in Spark. This produces results that align with ArcGIS Online and ArcGIS Pro outputs, which matters for organisations where spatial analytical answers need to reconcile across platforms.
Metadata-driven by default. Our standard framework absorbs ArcGIS service additions and changes as configuration. New Feature Services, new layers, and new attribute fields become metadata changes rather than pipeline rewrites. The framework survives the ArcGIS evolution that would break a hard-coded integration.
Engineered, not just built. CI/CD via Azure DevOps, version-controlled transformations, environment separation, and operational runbooks come as standard. The integration is engineered for production support, not assembled for the first demo.
