A tenant in SAP Integration Suite is an independent subscription unit tied to a single BTP subaccount, with its own message quota, its own user and role structure, and its own runtime. The standard practice at enterprise scale is to run separate Integration Suite tenants on separate BTP subaccounts for Dev, Test, and Prod, then move content between them through a controlled transport process.
Most teams that move to SAP Integration Suite start with the same question: how many tenants do we actually need? Running development, testing, and live operations on a single tenant looks practical at first, but a small mistake in the test environment can directly disrupt a live order or invoice flow. The standard approach in SAP Integration Suite is to set up separate tenants on separate BTP subaccounts for Dev, Test, and Prod, then move content, such as iFlows, mappings, and security material, between those tenants in a controlled way. In this article, we look at the classic three-tier landscape model, alternative approaches for smaller organizations, methods for transporting content between tenants, and the points teams tend to overlook when designing a landscape.
For a proof of concept or a pilot project, running development, testing, and live use on a single tenant looks cost-effective. However, this setup does not provide workload isolation.
An iFlow that is still being tested, or that is still under active development, can affect the performance or accuracy of a live process running on the same tenant. A mistake made in the test environment can corrupt a real order, invoice, or master data flow.
This risk does not grow with the number of tenants; it shrinks as environments are kept apart from each other. That’s why integration architects, including SAP itself, recommend hosting at least Dev and Prod on separate tenants.
In SAP Integration Suite, a tenant is an independent subscription unit tied to a BTP subaccount, with its own message quota, its own user and role structure, and its own runtime. Unlike the “one system, multiple clients” model in SAP PI/PO, each tenant is a fully separate service instance in its own right.
There’s an important cost reality here: SAP charges the same fee for a non-production tenant as it does for a production tenant. In other words, the assumption that “a test tenant costs less” simply isn’t true; the landscape decision is a budget decision as much as a technical one.
For high message-volume scenarios such as invoice automation, we covered how the message quota per tenant is calculated in our article Message Metric Calculations for SAP Integration Suite; these quotas need to be factored into any landscape planning.
The standard approach recommended at enterprise scale is to run three separate BTP subaccounts, each with its own Integration Suite tenant:
Each tenant has its own backend connection, through Cloud Connector, to the corresponding Dev, QA, or Prod SAP system. This means a mistake in the test environment never touches live data in any way.
In large organizations, this model can also be repeated by business unit. For example, finance, manufacturing, and retail units can each run their own separate Dev-Test-Prod landscapes. This approach provides autonomy, but it also requires governance to stay centralized and consistent.
Not every company has the budget or the integration volume to run three separate tenants. In that case, two common alternatives apply:
Two-tier landscape: Dev and Test are combined into a single tenant, while Prod is always kept separate. This lowers costs while still isolating the live environment.
Single tenant, dynamic configuration: In smaller-scale or lower-risk scenarios, iFlows running on a single tenant can read the environment (DEV/TEST/PROD) from an externalized parameter and switch the connection accordingly. This approach simplifies maintaining a single iFlow copy, but since it provides no workload isolation, it isn’t recommended for business-critical live processes.
Which model fits best depends on integration volume, team size, and how sensitive the live system is.
Moving an iFlow from Dev to Test and then to Prod works differently from the transport request logic in SAP PI/PO. SAP Integration Suite uses two common methods:
Content Agent + Cloud Transport Management (CTMS): The Content Agent service collects selected packages or artifacts from the source tenant; Cloud Transport Management then moves them to the target tenants through defined Dev to Test to Prod transport nodes. This gives you a centralized, auditable transport process.
Git-based approach: iFlows are versioned in a central repository using Git push, pull, and import features; approved versions are then deployed to the Test and Prod tenants from there. This method natively supports change history and comparison.
Whichever method you choose, three principles matter for the health of the landscape:
The main points to keep in mind when designing a landscape are:
SAP Integration Suite’s capabilities in this area keep evolving; you can follow the platform’s latest features in our article What is New for SAP Integration Suite?
Consider a company operating in multiple countries with a central SAP S/4HANA system. Say the integration team initially handles both development and testing on a single tenant, with go-live also happening through that same tenant.
As volume grows and new countries join the process, a mapping change deployed for testing purposes can temporarily halt the live order flow. At this point, the team sets up three separate subaccounts and tenants for Dev, Test, and Prod, and builds a centralized transport pipeline using Content Agent and Cloud Transport Management.
As a result, the development team keeps working freely in Dev, while Prod is updated only with content that has been approved and validated in Test; live processes stay completely isolated from ongoing development work.
Here are the steps to follow, whether you’re starting from scratch or migrating from an existing setup:
Each of these steps takes shape according to your existing SAP BTP account structure and your integration maturity; that’s why it pays off, in time and cost, to assess your current setup with an experienced integration team before making a landscape decision.
How many tenants do I need in SAP Integration Suite?
The standard recommendation is at least two tenants: one for Prod, and one non-Prod tenant that combines Dev and Test. At enterprise scale, and for business-sensitive processes, three separate tenants (Dev, Test, Prod) are recommended.
Does a test tenant cost less than a production tenant?
No. SAP charges the same fee for a non-production tenant as it does for a production tenant. Any cost advantage comes from reducing unnecessary tenants, not from the tenant type itself.
How do I move iFlows from Dev to Prod?
There are two main methods: controlled transport through the Content Agent service and Cloud Transport Management, or a version-controlled flow using Git push, pull, and import. Both provide a traceable process instead of manual download and upload.
Is it possible to manage Dev, Test, and Prod together on a single tenant?
Technically, yes; externalized parameters can let a single iFlow connect to different environments. However, since this approach doesn’t provide workload isolation, it isn’t recommended for business-sensitive live processes.
There’s no single right answer to tenant strategy in SAP Integration Suite; it’s an architectural decision shaped by integration volume, team structure, and risk tolerance. The one constant is that test and live environments need to stay isolated from each other.
At MDP Group, our SAP Integration Suite consulting practice runs these configuration projects end to end, from landscape design through transport strategy. If you’re curious how landscape decisions play out during a move from SAP PI/PO to Integration Suite, you can also check our SAP PO to SAP Integration Suite migration guide.
Sap Integration Consultant
Your mail has been sent successfully. You will be contacted as soon as possible.
Your message could not be delivered! Please try again later.
