Live vs Import Connections in SAP Analytics Cloud: The Decision
Almost every SAP Analytics Cloud model starts with a choice that quietly shapes everything after it: is this a live connection or an import connection? The two are not interchangeable, and choosing by habit rather than by requirement is how teams end up rebuilding models months later. The distinction is simple at its core — a live connection leaves the data in the source system and queries it where it sits, while an import connection copies the data into SAC and works on it there — but the consequences run deep, into planning, blending, data residency, and performance. In my advisory work the single most useful thing I can tell a team is the rule that resolves most of these debates before they start: if you need SAC planning, you need import. Everything else is a considered trade-off, and the honest answer for most enterprises is that they run both.
What each connection actually does
A live connection stores only the model's metadata in SAP Analytics Cloud. When a user opens a story, the query runs against the source system — SAP BW/4HANA, SAP HANA, SAP Datasphere, BPC — and the data is rendered without ever being copied into SAC. The numbers are always current because you are looking at the source, and the data never leaves its governed home. For SQL sources, SAC's live data access works slightly differently: Google BigQuery, Snowflake (since Q1 2026), and Azure SQL (since Q2 2026) are read through the data access agent on tenants running on SAP HANA Cloud, with the model structure kept in SAC and the fact data arriving at runtime as read-only live versions. An import connection does the opposite: it copies data from the source into SAC on a schedule, where it is stored and processed in SAC's own engine. You are now working on a managed copy, which unlocks SAC's full modeling toolkit but means the data is only as fresh as its last load.
When a live connection is the right answer
Reach for live when the source is already your governed source of truth and you want analytics to reflect it without a second copy. The strongest case is data residency: when security or compliance policy says the data must not be replicated into the cloud, a live connection keeps it in the source and stores only metadata in SAC — query execution happens on the source system. That single property resolves a lot of architecture-review objections that would otherwise stall a deployment.
Live is also the natural choice when currency matters more than flexibility — operational dashboards and statutory reporting where "as of the last load" is not good enough, and where the semantics defined in SAP Datasphere or BW/4HANA should be the authoritative version that everyone sees. You inherit the source's governed model rather than re-creating it in SAC. The trade-offs to accept knowingly: query performance now depends on the source system's performance, blending is more constrained than in import, and augmented features can lag on live sources — Smart Insights, for instance, worked only on acquired data and live SAP HANA until SAP extended it to SAP Datasphere and seamless planning models. Live is a discipline of trusting the source, and it rewards landscapes where the source is genuinely trustworthy.
When an import connection is the right answer
Reach for import when you need to do something to the data that SAC's own engine is built for. Planning is the decisive case: SAC's planning capabilities — budgeting, forecasting, simulation, write-back — are not supported on live connections to SAP BW or SAP Datasphere, so a planning model is an SAC planning model, with plan data stored either in SAC or, with seamless planning (since 2025), in SAP Datasphere. What changed is the actuals side: since the Q4 2025 release, planning models can read actuals as read-only live versions, from Datasphere for seamless planning models and from SQL sources such as Google BigQuery, Snowflake, and Azure SQL for others. If your requirement contains the word "plan," you need a planning model; whether its actuals are copied or live is now a separate choice.
Import also wins when you need to blend data from several sources into one model, when you want SAC's full data-preparation toolkit, or when you cannot afford to have dashboard performance hostage to a busy source system — because once the data is in SAC, queries run against SAC's engine regardless of what the source is doing. The price you pay is freshness and governance overhead: the data is a scheduled copy, so it lags the source, and you are now responsible for the load cadence, for reconciling the copy against the source, and for the fact that a second copy of governed data now exists. Import is more capable and less pure; that is the deal.
The honest answer: most landscapes run both
The mistake I see is not choosing wrong on any one model — it is choosing by default. A team standardizes on import because it is familiar and then fights data-residency reviews and stale-data complaints forever; or it standardizes on live for purity and then discovers six months in that the planning use case it was promised cannot be built. Decide per model, against the requirement, and write down why. The connection type is one of the few SAC decisions that is genuinely expensive to reverse once stories and models are built on top of it, so it is worth the few minutes of deliberation up front.