Hi,
First of all - this information does not apply to all SAP Analytics Cloud customers! In fact it's more of a minority group these days... But it's still a topic I discuss regularly, and i felt the time is right to share some details.
What are we talking about here?
At the beginning of our SAC journey, customers who were contracted from mid-2015 until Summer 2018 were provisioned into our SAP-Datacentres, which are called
NEO environments.
However from September 2018 onwards, new SAC subscriptions were delivered using
Cloud Foundry deployments. This fact was made clear in the contracts signed by our customers’ legal and procurement teams, but in our software user/help guides we chose not to muddy the waters too much.
However the sharp-eyed amongst you might have noticed some clues in the documentation that a divergence was under way - with statements like: “Non-SAP data centres host systems using two digits, such as eu10 or us30. Whereas Systems hosted by SAP data centres use one digit in their URL, like us1 or jp1”... often followed by slightly different configuration steps.
What does this mean in principle?
Now that we are deep into Q4 2020 it's become clearer that major new functionalities are being delivered into the Cloud Foundry codeline only, and that these enhancements are not (or cannot) be back-ported to Neo. There have been a few discussions along these lines in our own community
https://answers.sap.com/questions/12641207/why-is-smart-predict-only-offered-on-the-cloud-fou.html
Alas, I don't have the technical details, but my product management have told me that - amongst other factors - it's because Neo doesn’t benefit from Kubernetes container technology.
What are the main drivers to move?
Below, I've gathered a list of desirable features which might help drive SAC product adoption in your business and therefore lead to this migration conversation (probably this list isn't exhaustive, but the more prominent ones that come to mind):
- Scheduling Publications https://help.sap.com/viewer/00f68c2e08b941f081002fd3691d86a7/release/en-US/86c2d7d88b134e45907453612...
- Smart Predict scenario modeller https://help.sap.com/viewer/00f68c2e08b941f081002fd3691d86a7/release/en-US/37db2128dab44d15b46e19188...
- Cloud Platform Open Connectors https://help.sap.com/viewer/00f68c2e08b941f081002fd3691d86a7/release/en-US/c2789fc8f9af44f186a20a446...
- SAC Add-In for Microsoft Office https://www.sapanalytics.cloud/sap-analytics-cloud-add-in-microsoft-office/
- Live Connection to HANA Cloud (without need for Adapter) https://help.sap.com/doc/00f68c2e08b941f081002fd3691d86a7/2020.20/en-US/1c141f49943c4463b88ed8b147ff...
- Predictive Planning capabilities https://www.sapanalytics.cloud/guided_playlists/predictive-planning/
- SAC Co-Deployment together with Data Warehouse Cloud.
Who should consider this move?
As mentioned above, this information is mainly intended for customers who were contracted before Q4 2018 and that are still running the same SAC service unchanged on SAP NEO Datacentre.
By the way, when we say "SAC on Cloud Foundry" - this is principally meant as being SAC deployed on the hyperscaler 'AWS' (Amazon Web Services); and there are some notable exceptions around those who can't, or
wouldn't, consider AWS. Sometimes this is because certain industries, like Retail, perceived Amazon to be a competitor.
Below, I'll try to describe some other boundary constraints that I'm aware of:
Firstly, our Partner ecosystem weren't able to contract SAC via OEM or VAR agreements on Cloud Foundry paperwork until mid- 2019, so a good number of these partner subscriptions were deployed to SAP NEO initially as the fallback option.
Secondly, it's worth noting that (at time of writing) Cloud Foundry contracts still do not offer "EU Access Only" specification (this to ensure that the ‘data sub processors’ are strictly EU-based). This is often a legal constraint seen in the Banking industry, as well as Public Sector and others. I believe this is being resolved soon in 2021, as part of our future roadmap.
Thirdly, my understanding is that in the Greater China region, the Cloud Foundry hyperscaler of preference is Alibaba Cloud (a.k.a Aliyun) and that AliCloud was recently certified and is now supported by SAP for SAC deployments.
Furthermore, certain territories like in MENA (but also certain customers in specific regions) would not consider
anything other than a SAP-owned datacentre - hence
NEO-first due to legal or cultural preferences with regards to trust and assurance from their vendor.
However it is also of strategic importance that SAP customers be able to deploy SAC to other hyperscalers namely Microsoft Azure and Google Cloud Platform (GCP) - these are priority roadmap items for our future direction in 2021. This is all in the name of giving customers more choice on where they 'land and expand' their investment.
I need to transform - should I be worried?
Absolutely not. SAP-datacentres of type Neo aren't being ‘sunset’ at all, because it’s still strategic for SAP’s own OEM “embedding” effort into its solutions like S/4HANA, SuccessFactors, Cloud for Customer, Concur*, Ariba* etc. (*planned as per roadmap), as well as specific regions and/or customers that demand Neo.
As such, Neo DCs are still being built right now, although IAS (infrastructure as a service) isn’t necessarily an investment direction for SAP.
Therefore, from today's standpoint: this migration effort (moving SAC Neo to Cloud Foundry) isn't mandatory and isn't necessary for everyone who runs SAC on Neo. This information is simply for customer awareness and transparency of product communication.
How does this MOVE process work in principle?
Firstly, customers need to recontract through Sales - i.e. a Replacement contract - onto new Cloud Foundry agreements, which have a different SKU number internally on the bill of materials. It goes without saying contract values have to be the same, or more ? Also, the SaaS runtimes and other hosting parameters don't change either.
For our large enterprise and strategic customers, there is
some capacity to devise a
managed-move plan, kind of like an AMS (managed application service): we agree timelines for the tenant isolation, tenant backup, and ultimately - the actual migration activity. This task is done in conjunction with SAP's Cloud Operations team, but capacity is limited so we can't do this for everyone.
Current capacity for the
managed-move process is limited because SAP has only just started with this kind of migration service. However, the hope and expectations are that - in future - our operations will be able to scale and presumably, at some point in time, SAP will be doing this for many more subscribers.
Technically-speaking, SAC's underlying HANA-system and its repository are copied out of the SAP-datacentre, moved over to the hyperscaler environment; the schema is then restored into the new service, and the binding to the SCP subaccount is re-established. Sounds easy right?
The idea is that: when the customer resumes with their new service, all stories are there including models, users, teams, roles and licenses are exactly as they were, and all associated metadata including comments and hub/catalogue assets are restored as-is.
Additionally to this managed-move process, I’ve had customers who’ve additionally benefitted from a “white glove” treatment where SAP Services have helped with the reconfiguration tasks ‘post migration’ in the target environment. (More about those activities, and the split of roles and responsibilities below).
Conversely, other clients have been totally happy to do the whole exercise themselves – less reliance on us, more practice, and clean start for them... and likely a quicker turnaround! Broadly speaking: they export their content from Neo and import it into Cloud Foundry, then rebuild the configuration around it again – especially the security and authentication mechanisms, such as: re-establishing the Single Sign On (SSO) from their custom identity providers (IdP), reprovisioning users, team membership, and building-up the data access permissions and roles structures afresh. It's also worth pointing out that a
green-field scenario is a valid use-case for customers wanting to clean-up their system and/or consolidate content from different services.
Another potential ‘gotcha’ in the process is if the customer’s existing SAC subscription in Neo is a 'public service'. Under the covers this is a multi-container system, so there are probably other customers on the same 'blade'. It’s slightly more difficult to migrate to CF if these dependents don’t want to and requires an additional isolation step to be performed by our Cloud Operations. It’s much simpler however if your subscription happens to be a 'Private edition' (these are dedicated ‘single tenant editions’) with no dependencies, which can move autonomously without negotiations.
OK, I'm primed and ready - let's shoot!
Broadly speaking, the technical operations process takes about 2 days for one tenant – so the lift-and-shift can be done quite quickly. Note: there is a period of downtime that will need to be scheduled with the business - this is for the
tenant-isolation step. Depending on the size of the tenant, this can be up to 8 hours; and unfortunately this downtime can not be done during or coincide with the published maintenance weekends.
However, openly speaking, the entire exercise can take much longer, given the level of planning, discussions, commercial handshakes, and overall coordination required between and with our customers' business owners.
I need to reiterate again - the
managed move AMS-type process can't be offered to everyone today for reasons of scalability, so it's only reserved for our largest customer install-bases.
Also, it’s worth pointing out that there’s a first-in-first-out (FIFO) queue in process here, so
even if you are eligible then please expect a substantial lead time before a confirmed date can be agreed then aimed for.
I have also come to find out that, at time of writing, SAP doesn't offer a
managed-move migration scenario from Neo to AliCloud in the GCN region; so this is still an open roadmap topic.
What happens after the migration?
Basically, the customer has to integrate the SAC service back into their IT landscape again. Good news: Technical roll-out documentation has just been published to our microsite at
https://saphanajourney.com/sap-analytics-cloud/neo-to-cloud-foundry/!
Let's be honest - The customer needs to test, and test again. Several things come to mind that will need to be examined and adjusted (this list isn't exhaustive):
Unfortunately, the effort for troubleshooting and resolving these various hurdles is the sole responsibility of our customers and SAP can’t really get involved here (unless within scope of the consultancy service).
Obviously, and at a bare minimum, Stories will need to be checked and validated in the new service, and a new SAC URL will need to be communicated to your User community. Eventually, after a ‘grace period’, the old tenant will be suspended and shut down by our Cloud Ops when it's no longer needed.
What to do next if this is for you?
If your SAP Analytics Cloud service is running in a SAP-DC (identifiable by the URL format, as stated at the top of this article) and you want to move, then please contact your SAP representative through the usual channels: either go to your SAP Account Manager, your Customer Engagement/Success Executive or Quality Manager. I need to point out that: because the cloud contract needs to be amended, Product Support won't be able to action this for you if you log an incident.
Phew! That was long, but I hope not too rambling...
Remember SAP is here to help, our door is always open. Feel free to comment below the blog and I’ll do my best to respond.
Kind regards,
Henry, Customer Engagement Executive
SAP Analytics, Platform & Technology
