Earlier this year, SAP rolled out a comprehensive enablement program as part of the 2025–2026 migration strategy to ensure SAP IBP customers and partners confidently adopt the new Harmonized Planning Area (I_SAPIBP2),
SAP IBP’s HPA 2026 Strategy: Unified Planning and … – SAP Community
With the release of the MOVE2H tool (2605 release), SAP can support migrating existing IBP customers with SAP7F or SAP7-based order-based planning areas to I_SAPIBP2. The blog below contains some of the important technical pre-requisites with important tips and FAQs to help you kick-start with your HPA migration journey (Brownfield)
SAP has developed a comprehensive Migration Guide specifically designed for customers moving from their existing OBP planning areas to the Harmonized Planning Area (HPA), which is currently available only to early adopter customers and will be generally available soon.
Pre-Requisites: Before Getting Started
1. Know Your Migration Path
Before anything else, it is critical to identify which planning area you are migrating from, as this determines the complexity and the steps involved:
2. RTI Setup — Critical If You Are on SAP7 with SDI
- Start with the S/4HANA side first. S/4HANA system upgrades — service packs or specific support notes — may be required. As seen earlier, it can take a long time to setup for customers on older S/4HANA or ERP versions. Note 3106619 – SAP IBP Real-time integration – Notes for installation – SAP for Me describes which support packages or notes you need to implement, depending on your release. The linked report CIF_NOTE_IMPL_SUPPORT_IBP will help identifying necessary notes.
- You can use a dummy planning area (an independent copy of I_SAPIBP2 planning area) as a target for the RTI integration profile, so you do not have to wait for the full migration to begin.
- SAP provides a web-based application called CIAS (Cloud Installation Agent Support) that helps accelerate the setup of the Cloud Connector and all related connections as a kind of workflow.
Before starting with the migration make yourself familiar with the following information:
RTI Central Note: 3110007 – IBP Real-time Integration: Information/Restrictions – SAP for Me
3. Time Profile — The Most Critical Configuration Element
The time profile is one of the most important aspects of HPA migration. There are four specific areas related to the time profile to assess and resolve before proceeding:
- Custom Time Profile Levels
Check your planning area's time profile for any custom (user-defined) levels — for example, a fiscal year structure or custom quarter definitions.
Additional Attributes on Time Profile Levels
Check whether your time profile levels have additional custom attributes assigned. You need to attach them to the target time profile BEFORE the migration as well. Plan for Future Merging of Planning Areas; Consider whether you plan to merge multiple planning areas (e.g., order-based and time-series-based) now or in the future. Define the time profile with the union of all levels from all planning areas that may eventually be harmonized. Adding levels later is not possible. Adding attributes to existing time profile levels can be done at any time, but it is recommended to do that BEFORE the migration and before you load any data into the target time profile.
- Understand How Your Period IDs Were Created
The Period ID (a technical identifier for each time period) is used internally across planning views, filters, and all other objects. The migration tools currently assume a one-to-one mapping of Period IDs between source and target. If you are unsure how your time profile was originally created (SAP standard numbering, manual upload, custom job), download the time profile CSV from the Data Integration app and share it with SAP Product Management.
4. Assess Your CI-DS Integration Strategy
CI-DS (Cloud Integration Data Services) can continue to be used with HPA. However, there are important nuances to evaluate before migration:
- The existing CI-DS extractors are built on the data model of SAPIBP1. To continue using CI-DS with HPA, custom content would need to be copied and adjusted to the new data structure.
- Alternatively, this migration is an opportunity to switch to Cloud Integration (CI, SAP's recommended technology), where SAP provides predefined data flows.
The choice between continuing with CI-DS and adopting CI is a strategic decision that involves both effort and long-term benefits. This decision should be made before the technical migration begins.
In Addition to the above prerequisites, it's helpful to review some frequently asked questions (FAQs) from the Early Adopter Care (EAC) program initiative.
Question | Answers |
How can we raise access to the Migrate Configuration app for migration to an I_SAPIBP2-based planning area, as SAP Help states that this is currently an Early Adopter feature?
| To get access to the migration tool, an incident must be raised via component SCM-IBP-CNF-M2F |
Will CI-DS continue to work with HPA? Since CI-DS targets a specific planning area, do all CI-DS interfaces need to be modified? | Yes, CI-DS can continue with HPA, but existing CI-DS extractors are based on the SAPIBP1/SAP 7F data model. To use CI-DS with HPA, you must build your own content. Alternatively, use this migration as an opportunity to switch to SAP Cloud Integration (predefined data flows). |
We are migrating from SAP 7F and already have RTI in place with custom planning levels in OBP. Do we need to recreate those custom objects for the new planning area? | No. All configurations — custom key figures, planning levels, attributes — are supported by the migration tool. Having RTI already in place will significantly accelerate the process. Some manual pre- and post-migration adjustments will be needed before the planning area activates |
We migrated from SAP7 to SAP7F and now want to go to HPA. Do we need to predefine all future time profile-level attributes, or can they be defined later? | Time-profile-level attributes can be added later, but it is recommended to ad them before the migration. What cannot change is the structure and order of the time profile levels themselves (which determines the internal period ID numbering). |
Does the existing HPA support subnetwork planning in OBP, or is that a future roadmap item? | Yes, subnetwork planning is currently available in OBP. The 2611 roadmap item is specifically for time series supply optimization — not OBP. |
Does the migration guide/tool provide field-level mappings — specifically, old 7F attribute IDs mapped to their HPA counterparts? | Yes. The tool contains all mappings in table form. |
Historical data/KPIs — is there an automated tool for preserving them, or is it manual? | No automated tool support for data migration. If KPIs are stored as key figures in the old planning area, with equivalent key figures in the target, set up a copy operator to copy data from the source to the target, with attribute mappings defined between the two planning areas. |
Our SAP7F is a non-cached version. Do we need to manually update the data source for each key figure to use cached data? | For SAP standard SAP7F key figures: no change needed. Only custom key figures with non-standard external data sources that reference non-cached order key figures need manual updates after migration to point to the cached data source. |
HPA has cached key figures built in — so we don't need to switch them on separately, right? (Are these the OKF Keyfigures?) | Correct. Cached order key figures are enabled by default in HPA. It is a one-way setting — you cannot revert from cached back to non-cached. |
Can two different forecast key figures be assigned to two different planning levels (one at product-location-customer level, another at product-location level)? | Yes, technically. The allocation profile and forecast consumption profile configured per product determine which level the system reads for each product. If it worked in SAP7F, it would work in HPA . |
Can we add custom attributes now to time series planning levels in an existing live HPA planning area that was set up for a different purpose? | Yes. Adding non-root attributes to an existing planning area is possible. |
We have a live time series planning area and a live OBP planning area. The plan is to first migrate OBP, then merge time series 1.5–2 years later. Will that be possible? | It is on the roadmap. The key prerequisite today: the time profile in the HPA target must contain all time profile levels from both planning areas before the first migration, and it is recommended to contain all attribute then as well (not mandatory). |
My migration app view looks different from what you are demonstrating, and I don't see the same grouped options | You are missing the new business catalog that enables the enhanced grouped UI. If access was requested some time ago, the catalog may not have been assigned. Raise an SAP support ticket to have the new business catalog enabled. With release 2608, it will be automatically available in all systems |
If I made a mistake in the mapping, can I delete the profile, create a new one, and restart? | Yes. You can reuse an existing mapping profile in a new migration project or create a new one. However, only restart before making any manual adjustments to the target. If manual adjustments were already made and you re-run migration, those adjustments will be overwritten |
We have an active RTI profile for SAP7F. Can we create a second RTI profile for the new HPA planning area while both connect to the same S4/ERP system simultaneously? | Yes. You need two different logical systems in S4 (SM59) — one per planning area. Inbound integration can run in parallel from the same ERP to both planning areas. Outbound integration must NEVER run from two planning areas simultaneously for the same data. Separate logical systems also help distinguish body logic between SAP 7F and HPA in your BADI development, as the data structure has changed and some BADI might need to be adjusted (e.g. on PDS). |
With two integration profiles, will the data flows for each planning area be fully separated even if using the same source data? | Yes. Different change pointers, completely independent data flows, separated by planning area. |
There are ~200 OSS notes required for RTI setup in ECC. Should those be implemented before CIAS setup, or can they go in parallel? | They can mostly go in parallel. For most systems not on very old ERP 6.0, ~95% of CIAS setup can proceed in parallel with note implementation |
We have custom staging tables in SDI that contain transformed data feeding into EXT tables. Can we reuse those custom staging tables as data sources in RTI BADIs? | Yes. Custom Z tables or standard X tables can be used as sources in RTI BADI logic |
I want to migrate content in stages (planning filters first, then analytics, etc.) while making changes to the target in parallel. Will re-running migration reset the target to the source state? | Yes. Re-running migration overwrites objects in the target. Make all changes in the source first, then migrate. Do not modify the target expecting those changes to survive a subsequent migration run |
Does cross-planning-area (inter-planning-area) copy operator migration also work, or only within-planning-area ones? | Yes, inter-planning-area copy operators are also supported, with restrictions. Only copy |
Roles and authorizations — if copy operators or application job templates get new IDs after migration, do the role assignments get migrated too, or need to be recreated? | Business roles are not touched by the migration. Any role referencing technical names of application job templates or copy operators must be manually updated |
Does the migration support a three-tenant IBP architecture? | No change. ATO (Advanced Transport Organizer) handles three-tier landscapes as standard. |
We have a custom attribute-as-key-figure used in many calculations. In the source it is simple external master data type, but the target mapping points to a reference master data type. How do we add this attribute to the target? | Two options: (1) Add the attribute-as-key-figure to the simple master data type and make it available in the reference master data type; define the key figure base level accordingly. (2) Create a simple master data type with the same primary key as the reference master data type; add the custom attribute there; add this MDT together with the attribute to the planning level — the system will find it via shared key. |
We cannot reuse the SAP7F RTI integration profile for HPA, correct? | Correct. Do not reuse the SAP7F RTI profile for HPA. Run the two workstreams in parallel: RTI provisioning (with notes) and HPA planning area configuration — no data flow needed during configuration phase. |
We cannot create I_ key figures manually. How do we get new SAP standard 2608 key figures into our existing HPA planning area? | Two options: (1) Make a new copy of SAP IBP2 (sample), then use the compare functionality to select specific key figures and merge them into your planning area. (2) Use the new “partial merge” functionality in 2608 from the sample model entity app |
The source attribute has a decimal data type but the HPA target attribute is integer (e.g., frozen distribution horizon). Can we change the data type in the target? Can we increase the attribute length? | Data type changes: only possible before activation. Once activated, data types cannot be changed. Attribute length changes: strongly discouraged. Any attribute in application mapping or RTI has strict length/type requirements. Changing field length or data type of standard attributes can cause activation and integration to fail |
Can disabling the new uppercase-only setting on a target attribute cause activation errors? | No. There is no activation check on the uppercase setting. It is only a data consistency control |
After migrating to HPA, some calculated key figures take longer to refresh in planning views than they did in SAP7F. Are there best practices for HPA performance? | Standard key figures should not be slower in HPA than in SAP7F. For calculated key figures, the cause is likely a configuration issue |
When transporting the planning area to quality/production — how does the migration profile know the planning area step is done? Do we need to manually mark it as successful in QA/prod? | Yes. After transporting the, planning area, application mapping, and migration profile to the next tenant, manually set the planning area migration step to “success” there. Then migrate remaining objects — especially non-transportable ones (e.g., planning filters created by planners directly in Excel in that system). |
We have a SAP7F config planning area and a production planning area. Does the HPA migration mandate the same two-layer architecture? | Not mandatory. You can migrate using only the production planning area as source. If the config planning area is always ahead (new features developed there) and production lags, migrating config first is easier You can then copy the migrated planning area, create a new migration project to it, assign your custom mapping profile and manually set the planning area to success. Then you can start migrating other objects such as excel planning view favorites that might only exist in the second planning area, |
We are currently migrating OBP SAP7F. In a few months we may want to add demand planning to the same HPA planning area. Since demand migration requires the target not be productive, how does that work once OBP is live? What is the timeline? | SAP is developing brownfield migration tools for IBP1 into IBP2 — target timeline approximately mid-2027. The merge migration scenario (demand into an already-productive IBP2 planning area) is the specific feature being developed. In the meantime: (1) Wait for merge migration tooling (~mid-2027). (2) Manual approach: modify the IBP2 planning area to support demand operators |
Happy Reading! 🙂
Source link
