Road to Seamless Planning :: SAC Migration :: 4 :: Move and Test 

Introduction 

After three weeks of migration, we now enter the final phase—moving content to the new SAP Analytics Cloud (SAC) tenant. We decided to use 5.3.8 (Content Network) to move our content, skipping 5.3.5 (Export Content) and 5.3.6 (Import Content), to save time and not facing limitations as described in the next sections.  

Pre-steps 

Before starting the actual content migration, we had already completed the following steps: 

With the groundwork in place, we moved forward with the content migration. 

5.3.8 Move Content (Content Network) 

According to the SAP guide „Migration of SAP Analytics Cloud within a Cloud Foundry Landscape,“ the Content Network has the following limitations: 

  • Content Network can only be used for migrations within one landscape. This means that it cannot be used for cross-landscape moves including:  
  • Migrations from Neo to Cloud Foundry,  
  • Migrations between EU Access and non-EU Access landscapes,  
  • Moving between different data center regions like from USA to Canada,  
  • Migrations from one hyperscaler environment to another.  
  • The source and destination systems must be on the same or the following quarterly version of SAP Analytics Cloud. If the importing system is on an older version, the package will not appear. If it is two or more versions ahead of the exporting system, the package contents might not be supported. 

Luckily, we were able to use the Content Network and attempted to create a package containing all objects from the Public Folder (except for connections, which were already transported). 

Optimistic approach 

Our first approach was to migrate the entire Public Folder in one step. We selected all objects in the source tenant while excluding the already-moved connections.

 

Issues Encountered: 

  • After 30 minutes, the transport package appeared in the target queue. 
  • Importing the package took a long time as SAC performed consistency checks on each click. 
  • Incompatible objects caused import failures since our new tenant only allowed new objects. 

Key Takeaways: 

✔️ Classic stories and applications need migration or won’t be moved. 
✔️ Smaller transport packages are more efficient and flexible. 

Converting Classic Stories and Applications to Story 2.0 

We are now beginning the process of converting our stories and applications. Our goal is to retain the stories that are actively used and those that serve as useful examples for future development. This migration also provided an opportunity for housekeeping, allowing us to remove obsolete objects and reorganize our folders. While this cleanup required some effort, it will significantly streamline the upcoming conversion and content migration steps. 

Use conversion tool 

We used the conversion tool to migrate classic stories to Story 2.0. While the tool successfully converted 40% of the stories, we encountered issues where the process would freeze mid-conversion without displaying any error messages. In these cases, we had to identify the problematic story manually and then restart the conversion tool.

 

For some stories and applications, we received an error stating that the underlying models needed to be active before migration. As a result, we had to reactivate systems and connections to proceed with the conversion—even when our primary goal was simply to preserve the scripting. 

Applications cannot be converted using the auto-converter and must be migrated manually, requiring each application to be opened and converted individually. Performing a thorough cleanup beforehand helps streamline the conversion process and reduces overall effort.

 

During the conversion process, there may be cases where Story 2.0 does not support certain features from the classic version. One example of this limitation is the „Input Task“ functionality, which is not fully retained after migration. 

Key Takeaways: 

✔️ Ensure underlying models are active before conversion. 

✔️ Some features may not be retained after migration. 

✔️ A cleanup beforehand reduces migration time. 

✔️ Application migration is manual and time-intensive. 

Step by step approach 

After cleaning up the system and converting stories, we felt ready to move content to the new tenant. 

Instead of migrating everything at once, we created smaller transport packages per folder. 

Smaller packages transferred significantly faster (~10 minutes) via Content Network to the new tenant. The import process was more efficient, allowing for quicker selection and deselection of objects, and making error handling much easier. 

However, we encountered several issues when importing, particularly with native models. To resolve this, we identified problematic objects, adjusted them in the source system, and transported them separately. 

We successfully moved content in approximately 50 transport packages from the old to the new tenant. 

Key Takeaways: 

✔️ Clean up first to avoid unnecessary migration. 
✔️ Use smaller packages for faster transfers. 
✔️ Be prepared for a lengthy validation process. 

5.3.9 Known Issues 

In manual migrations, some objects cannot be moved, such as:  

•  Activity logs  

•  Comments  

•  Scheduling/Publishing information  

•  Predictive scenarios  

•  Objects and folder level security information  

•  Content network package stored in Content Network  

•  All other configurations (Tenant level, users)  

•  Calendar entries 

Lastly, we confirmed that all known issues were indeed valid. In our case, losing logs or comments was acceptable, but for production systems, these limitations could become critical and potentially a showstopper.

Conclusion 

After 30 hours of work, we successfully migrated all stories, moved content, and tested functionality on the new tenant. However, we underestimated the complexity of migrating stories and applications, which consumed most of our time. 

Final Takeaways: 

✔️ Clean up first to reduce migration workload. 
✔️ Migrate stories and applications first. 
✔️ Use smaller packages when moving content via Content Network. 
✔️ Do not underestimate the effort required for story and application migration. 
 

After a 30-day migration period, we successfully moved all necessary content to the new tenant. With the old tenant now decommissioned, we look forward to a seamless planning experience in SAP Analytics Cloud. 

Related Blogs

Minimum Viable Product with Seamless Planning
Road to Seamless Planning :: SAC Migration :: 1.0 :: Setup
Road to Seamless Planning :: SAC Migration :: 2 :: Setup security settings
Road to Seamless Planning :: SAC Migration :: 3 :: Migration of content from the source tenant to the new tenant 

Author: Mario Nadegger

Mario Nadegger is a Managing Director and Business Intelligence Solution Architect, specializing in SAP Analytics Cloud (SAC). As a leading SAC expert, he has extensive experience in designing, implementing, and managing SAC solutions, including SAC Native Planning, reporting, and integration with SAP BW/4HANA. His strengths lie in strategic SAC architecture development, establishing design guidelines, and enterprise-wide SAC implementation. With his role as a managing director, he combines technical excellence with business leadership, driving innovative BI strategies. As an architect, team leader, and developer, he acts as a crucial bridge between IT and business, enabling digital transformation.

×