The SAP Cloud Platform Mobile Services can be seen as an innovative successor of the SAP Mobile Platform. For customers who want to migrate to Mobile Services it is often not easy to get started. The following blog provides guidance to start planning the migration. And there are plenty of migration options available.
Let’s start with a short summary, why a migration makes absolute sense.
There are some obvious reasons to migrate a piece of infrastructure software to the cloud in general. These reasons are the ones you hear always when it comes to cloud advantages and they are certainly true for migrating to Mobile Services as well. Reduced complexity and maintenance as well as faster access to innovations – let’s take a closer look on these two.
Complexity of software systems can be overwhelming. For SAP Mobile Platform (SMP) it is not very difficult to come up with a large landscape, as depicted below. Here we have, for each landscape (development, test & quality, production) SMP nodes and databases, a Reverse Proxy in the DMZ and the mobile devices in the internet. All these boxes need to be managed. You need to:
SAP Mobile Services on the opposite is quite elegant in its architecture:
The only on-premises installation you need to care about is the SAP Cloud Connector. Everything else is managed by SAP Cloud Platform, you get automatic installation of patches and new features and you will be always up-to-date. No OS updates, no DB updates, backups you need to care about.
And in order to make sure you don’t run into regressions, you get a preview landscape that runs always a version ahead of the production landscape.
The other aspect is that cloud software gives you faster access to innovations. The following picture shows a summary of the feature scope of SAP Cloud Platform Mobile Services:
As you can see there are a lot of features that are available as building blocks to be re-used by your mobile solution. Some of them are the same as in SMP, like push notifications or the offline sync engine. But many of these features are not available in SMP. On the development side these are the native SDKs, SAP Cloud Platform SDK for iOS, SAP Cloud Platform SDK for Android, then we have the Mobile Development Kit (which also supports iOS and Android, cross-platform) and last but not least the SAP Mobile Cards.
Features which has been added to Mobile Services only are for example the discovery service – a service that would not be even possible as an on-premises software. Or integration into the Document Service, which gives you access to a repository of files. Some of the features of Mobile Services re-use other SAP Cloud Platform services. For instance, the usage analytics feature, merges SAP Analytics Cloud features into Mobile Services. This would not be possible with SMP.
This synergy is what makes SAP Cloud Platform, and Mobile Services in particular, the strategic future for our Mobile technology portfolio.
I guess this should shed some more light on why going Cloud for mobile solutions makes total sense. It’s time to discuss the “how”.
The entry point into a migration discussion is to consider the application type. Usually, our customers run different kind of apps on the same SMP and the migration path needs to be considered for each application individually. The table below gives you a rough guideline on how to migrate.
For application that have been developed with the SAP Mobile Platform SDK and in particular on the OData stack, the migration is the easiest, because the apps can be reused. Often you just need to rollout a new version of the app which points to Mobile Services.
If you are using Agentry-based applications you may want to consider moving the Agentry part of the app to SAP Cloud Platform as well and migrate to SAP Work Manager, cloud edition or SAP Inventory Manager, cloud edition. This will result in an architecture where the local Agentry server will be replaced through an Agentry-as-a-Service component on SAP Cloud Platform. Since the back-end add-ons and the application keep the same, this migration is typically a low hanging fruit. You can also keep all your customization. If you are running on an older version of the Apps, you need to upgrade to the latest version of the respective app – this will render the effort to medium.
If you run MBO based apps, the migration path is usually to re-develop the mobile solution and migrate the MBO to an OData Services.
Migration of MBO based apps is a great opportunity to adapt new technologies as the SAP Cloud Platform SDK for iOS or the SAP Cloud Platform SDK for Android. On the back-end side, we do offer help to migrate off the MBO stack with the MBO façade (an interims step for migration), with the Exchange Table framework, that let you develop change tracking for OData Services – something that is needed for delta token support in OData services in SAP Gateway and maybe the Mobile Back-End Generator I mentioned in my earlier post can be helpful to you as well. A lot of useful and detailed migration information for the various technical migrations can be found in our documentation here: migration guide
I want to close my blog with some advice for your migration:
Have fun,
Martin
Let’s start with a short summary, why a migration makes absolute sense.
There are some obvious reasons to migrate a piece of infrastructure software to the cloud in general. These reasons are the ones you hear always when it comes to cloud advantages and they are certainly true for migrating to Mobile Services as well. Reduced complexity and maintenance as well as faster access to innovations – let’s take a closer look on these two.
Complexity of software systems can be overwhelming. For SAP Mobile Platform (SMP) it is not very difficult to come up with a large landscape, as depicted below. Here we have, for each landscape (development, test & quality, production) SMP nodes and databases, a Reverse Proxy in the DMZ and the mobile devices in the internet. All these boxes need to be managed. You need to:
• Update SMP and apply service packs
• Update underlying OS
• Update DB systems
• Backup DB systems and servers
SAP Mobile Services on the opposite is quite elegant in its architecture:
The only on-premises installation you need to care about is the SAP Cloud Connector. Everything else is managed by SAP Cloud Platform, you get automatic installation of patches and new features and you will be always up-to-date. No OS updates, no DB updates, backups you need to care about.
And in order to make sure you don’t run into regressions, you get a preview landscape that runs always a version ahead of the production landscape.
The other aspect is that cloud software gives you faster access to innovations. The following picture shows a summary of the feature scope of SAP Cloud Platform Mobile Services:
As you can see there are a lot of features that are available as building blocks to be re-used by your mobile solution. Some of them are the same as in SMP, like push notifications or the offline sync engine. But many of these features are not available in SMP. On the development side these are the native SDKs, SAP Cloud Platform SDK for iOS, SAP Cloud Platform SDK for Android, then we have the Mobile Development Kit (which also supports iOS and Android, cross-platform) and last but not least the SAP Mobile Cards.
Features which has been added to Mobile Services only are for example the discovery service – a service that would not be even possible as an on-premises software. Or integration into the Document Service, which gives you access to a repository of files. Some of the features of Mobile Services re-use other SAP Cloud Platform services. For instance, the usage analytics feature, merges SAP Analytics Cloud features into Mobile Services. This would not be possible with SMP.
This synergy is what makes SAP Cloud Platform, and Mobile Services in particular, the strategic future for our Mobile technology portfolio.
I guess this should shed some more light on why going Cloud for mobile solutions makes total sense. It’s time to discuss the “how”.
How do you get there?
The entry point into a migration discussion is to consider the application type. Usually, our customers run different kind of apps on the same SMP and the migration path needs to be considered for each application individually. The table below gives you a rough guideline on how to migrate.
| SDK App Type | Replacement in SAP Cloud Platform | Migration Effort | Migration Strategy |
| SAP Mobile Platform SDK | Re-use | Low | Re-deploy |
| SAP Work Manager SAP Inventory Manager | SAP Work Manager or SAP Inventory Manager, cloud edition | Medium | Adapt |
| MBO App | Native Mobile Development Kit | High | Re-develop |
For application that have been developed with the SAP Mobile Platform SDK and in particular on the OData stack, the migration is the easiest, because the apps can be reused. Often you just need to rollout a new version of the app which points to Mobile Services.
If you are using Agentry-based applications you may want to consider moving the Agentry part of the app to SAP Cloud Platform as well and migrate to SAP Work Manager, cloud edition or SAP Inventory Manager, cloud edition. This will result in an architecture where the local Agentry server will be replaced through an Agentry-as-a-Service component on SAP Cloud Platform. Since the back-end add-ons and the application keep the same, this migration is typically a low hanging fruit. You can also keep all your customization. If you are running on an older version of the Apps, you need to upgrade to the latest version of the respective app – this will render the effort to medium.
If you run MBO based apps, the migration path is usually to re-develop the mobile solution and migrate the MBO to an OData Services.
Migration of MBO based apps is a great opportunity to adapt new technologies as the SAP Cloud Platform SDK for iOS or the SAP Cloud Platform SDK for Android. On the back-end side, we do offer help to migrate off the MBO stack with the MBO façade (an interims step for migration), with the Exchange Table framework, that let you develop change tracking for OData Services – something that is needed for delta token support in OData services in SAP Gateway and maybe the Mobile Back-End Generator I mentioned in my earlier post can be helpful to you as well. A lot of useful and detailed migration information for the various technical migrations can be found in our documentation here: migration guide
I want to close my blog with some advice for your migration:
- Cloud business is different – please consider the commercial aspects of a migration
- Cloud operation is different – instead of updates projects for on-premises software, you need to invest in test automation
- Start small, learn, iterate and avoid analysis paralysis
- Less is more – Don’t migrate apps or features that are not used. Sometimes a migration is not worth the effort
- You can do it – you are not the first who have successfully walked that path
- Start today
Have fun,
Martin
- SAP Managed Tags:
4 Comments
