How to Understand AWS’s Advice on Migration

Executive Summary

• AWS has specific advice as to how to perform a migration to AWS.
• This is essentially a phased approach that scales with the customer’s capabilities and understanding.

Introduction

AWS sees substantial growth, but SAP and Oracle will resist leveraging the AWS cloud as this reduces their control over the account. Secondly, neither AWS nor Google is companies that “holds people’s hands.” They both have growing partner networks, but AWS and Google Cloud are still much more “do it yourself” than SAP or Oracle, which provide an army of consultants available to provide large amounts of expensive consulting. Instead, AWS and Google provide clear documentation for how to leverage their offerings.

Our References for This Article

If you want to see our references for this article and related Brightwork articles, see this link.

AWS has published the following migration graphic.

Their definition of these strategies are as follows:

1. Re Host: AKA lift and shift, which is where applications are moved without changes.
2. Re Platform: AKA lift, tinker, and shift. This is where parts of the application are changed; it is mostly kept the same when migrated. The example AWS gives is switching out WebLogic for the open-source Apache Tomcat. This makes sense when companies move to AWS. They find they can access many open-source items very quickly and easily.
3. Re Factor/Re Architect: One example of this AWS gives is migrating from a monolithic architecture to “serverless.” We cover monolithic versus microservices later in the book.
4. Re Purchase: This moves from an on-premises license to SaaS.
5. Retire: This decommissions the application that is no longer needed.
6. Retain: This keeps applications that are critical for the business but must be refactored.

AWS provides this decision point diagram, which fits in with the different options.

Notice the term “retire technical debt.” On-premises environments have an enormous amount of technical debt. They are filled to the brim with applications they don’t get value out of, high overhead support costs. They also have too many skills required for the items they are trying to control, which means many components are not appropriately managed. This prevents these companies from gaining the full benefits from their purchases.

Consistent with AWS’s recommendation to start simple, rehosting opportunities should be evaluated as one of the first items for companies to do. They are the “low hanging fruit.” SAP and Oracle have been exaggerating their cloud capabilities for years now. Companies that are using SAP or Oracle for hosting should ask themselves why. It only takes a brief evaluation of either SAP or Oracle Cloud to easily tell that this is not something that SAP or Oracle has been good at doing. Both SAP and Oracle receive roughly 16% of their revenues from the Cloud, but for SAP, most of this is from SaaS acquisitions and not from SAP Cloud. Oracle coerces customers into purchasing cloud licenses, so their reported figures are unreliable, as we will cover further in this book. When we discuss IaaS rather than SaaS, SAP and Oracle shrink to a tiny component of each company’s revenues.

AWS proposes migrating consistent with the maturity of the customer, as is covered in the following graphic.

AWS sees these factors as determining what and when, and even if to migrate different components to the Cloud.

When migrating, AWS proposes the following steps.

1. Test Systems at Production Scale: This can be accomplished on AWS because it is easy to spin up a production-sized environment. Furthermore, it can be brought up for just a short period and deactivated in between usage periods. This can be considered a “test on demand.”
2. Automate to Make Architectural Experimentation Easier: A big part of this is replicating systems.
3. Allow for Evolutionary Architectures: This is “build to change.” This is where automation and on-demand testing come into play.
4. Drive Architectures Using Data: Where data collection comes into play based upon the workloads you apply.
5. Improve Through Game Days: This is a simulation. You simulate as many realistic factors as you can on planned days.

Making the Business Case for Migration

AWS proposes that five areas make up the case for migration. These are the following:

1. Business Agility
2. Operational Resilience
3. Cost Avoidance
4. Workforce Productivity
5. Operational Costs

AWS provides the case study above as an example of the case for migration.

We see several things left out of this, one of the most important being test. This book will frequently refer to the enhanced ability to test solutions before committing to solutions, as this is a primary distinction between on-premises and Cloud. In traditional SAP and Oracle on-premises implementations, one must invest time in things like hardware sizing. The sizing process often becomes so time-consuming that the sizing became a large percentage of the purchased final hardware price.

SAP was notable for providing a “Quick Sizer” that was quite inaccurate. The problems with sizing SAP and Oracle extend beyond just the time-consuming nature of sizing exercises and inaccuracy. For example, with SAP’s HANA database, SAP deliberately released information that would cause customers to undersize the HANA so that the initial purchase would be based upon pretenses. This topic is covered in the article Understanding Pricing in S/4HANA and HANA.

None of these things happen with AWS or Google Cloud. This is because of the ability to test without making anything but a short-term commitment. AWS and Google Cloud’s capacity is an “ocean” where the customer can access any percentage of this ocean of capacity. There is simply no comparison in this area with SAP or Oracle. For example, SAP has the SAP Cloud, and Oracle has the Oracle Cloud, which SAP and Oracle tout as being this “ultra-flexible” IaaS/PaaS. SAP and Oracle are trying to pretend that they offer to customers what AWS and Google Cloud provide.

The growth of AWS and Google Cloud versus SAP Cloud and Oracle Cloud illustrates that companies are clearly choosing AWS and Google Cloud (and Azure). Google’s growth is, of course, slower than AWS that leads everyone. Moreover, as we will discuss, Google Cloud is a better fit for some customers and some scenarios. AWS and Google Cloud share many similarities, but they also have important differences that we will illustrate in this book.

What is Being Migrated to or Accessed in AWS and Google Cloud?

This book discusses migration, but migration is only part of the story with leveraging the Cloud for SAP and Oracle. Increasingly, companies will place more custom components into the Cloud that will integrate back to on-premises systems, all while leveraging cloud services. AWS’s software will even manage on-premises resources and co-manage with open sources cloud management projects like OpenStack and CloudStack. That is why the book is titled “How to leverage” rather than “how to migrate.”

A Brief Overview of AWS and Google Cloud Services

We have discussed a few services already, but to put some firm roots down, let us review what AWS and Google Cloud offer customers concerning specific services.

The list below includes some of the most popular services provided by either AWS or Google Cloud.

Most of the most commonly used AWS services map very well to those offered by Google Cloud. A primary difference between AWS and Google Cloud is that AWS has far more services. If we provided a more extensive list, the difference would become apparent. But many of AWS’s services don’t have nearly as much usage as the services listed in this table.

Constant options are a feature of AWS and Google Cloud. Furthermore, the ability to adjust the service is unprecedented in the history of IT. Lengthy sizing exercises are a feature of on-premises implementations. Moreover, once an application/database license and the hardware were purchased, there was a forward momentum to using the solution “as planned.”

In many cases, lengthy sizing exercises have resulted in sunk cost decision-making orientation that kept solutions in place that did not add value.

SAP and Oracle’s High TCO

Something critical is how SAP and Oracle do everything they can to hide the TCO of their databases and applications. One of the authors of this book, Shaun Snapp, wrote the only book on enterprise software TCO calculation titled Enterprise Software TCO. Brightwork Research & Analysis has the most complete Enterprise Software TCO calculators. (available online and free)

As part of this book’s research on the author, Shaun Snapp, both vendors and consulting companies provide either inaccurate or incomplete TCO. SAP has paid Forrester on multiple occasions to create misleading TCO studies for SAP applications.

We conclude that consulting companies and vendors want their customers to know the TCO of their offerings. This is about how any person in sales wants his customers to know the TCO of their purchase. That translates into not at all. Moreover, as most sales, on-premise software sales are about emphasizing the license purchase. This is true even though research at Brightwork Research & Analysis indicates that the average application’s license is only (on average) 10% of the TCO of its lifetime costs. Knowing this, is it somewhat shocking how often we have observed software buyers focus most of their attention on the initial purchase price.

Once again, AWS and Google Cloud are not software vendors, so they work a bit differently. Both AWS and Google Cloud are predicated upon massive infrastructure investments. These enormous investments and overall low overhead sales and access approach lower costs. AWS and Google have the highest orientation around cost reduction and economies of scale of any of the entities we have studied in enterprise software. Also, because they offer a low TCO, they have a unique incentive to allow customers to calculate the TCO using their services.

They offer an easy-to-use TCO calculator.

This is the basic version of the AWS TCO Calculator

The overall transparency with AWS and Google Cloud is significantly increased. AWS customers are notified of their monthly charges by email, even if they don’t log in to their AWS consoles. We will get into this topic in more detail in our chapter on pricing.

Furthermore, as we cover in other parts of this book, we predict that AWS and Google Cloud infused SAP and Oracle environments will lower their TCO. For one reason, companies pick up a great deal of flexibility in their infrastructure. Secondly, using AWS and Google Cloud makes the implementing company less reliant on SAP and Oracle consulting partners. AWS and Google Cloud’s self-service nature makes it a simple matter to project that the consulting multiple versus costs. This is, in our view, the most significant opportunity for releasing IT funding to be applied to higher-level uses.

AWS Further Eases Database Migration Away From Oracle

Oracle has based its database business around lock-in. As I have covered in previous articles, there is an immense opportunity to reduce costs by migrating away from Oracle databases to databases like PostgreSQL or MariaDB, or others. However, something that is required is a managed DB. There is no point in migrating away from Oracle DBAs if something else cannot take its place.

Well, something did.

AWS’s Managed Services

AWS came up with the managed DB through its managed services, which manages overall infrastructure, databases being one component of this. This AWS has had for a while. However, migration has been performed by consulting firms with expertise in AWS. AWS has recently “greased the skids” for companies with the desire to migrate databases to AWS. And also to migrate away from the database to different databases. Let us see the following quotation from the AWS website.

“The service supports homogenous migrations such as Oracle to Oracle, and also heterogeneous migrations between different database platforms, such as Oracle to Amazon Aurora or Microsoft SQL Server to MySQL. You can also use AWS DMS to stream data to Amazon Redshift, Amazon DynamoDB, and Amazon S3 from any of the supported sources, including Aurora, PostgreSQL, MySQL, MariaDB, Oracle, SAP ASE, SQL Server, and MongoDB. In addition, you can use AWS DMS for continuous data replication with high availability.” – AWS Website

“Options” But a Target on Oracle’s Back

AWS presents this as a bunch of “options,” but one database vendor is burning a hole in the company’s pockets with its expense and overhead, and this database is Oracle.

This quotation explains the details of how this is accomplished.

“With this launch, AWS DMS enables customers to use the same mechanic that the database uses for commit sequencing, which is the log sequence number (LSN). The launch also opens more integration use cases. For example, now you can use Oracle Data Pump or SQL Server BCP to do the initial data load into a target database and then use the DMS log sequence numbers to start change data capture (CDC). With the checkpoint feature.. you can replicate changes once a day from the last checkpoint.” – AWS Website

This conversion setup can be seen in the following screenshot from AWS.

Notice the options under the migration type. 

Conclusion

Companies can avail themselves of this new capability to migrate away from Oracle. Of course, many companies have customizations in Oracle, stored procedures, etc., that reduce the ability to migrate. However, those databases that can (other databases can be migrated by moving the stored procedures out of the database and into the application layer) enable one to migrate to an open-source database, which in the vast majority of cases can handle the workload just fine. With AWS’s Managed Services, it means that Oracle support can be dropped. This can be a boon to companies. It takes what amounts to what is widely considered close to no value and puts it back in the company’s pocket to spend on things that add value.