Migration considerations
In addition to the risk factors described for an all-at-once service rewrite strategy, here are some things to watch out for with a phased migration:
Dependencies between the phases
As you migrate from on-premises to serverless, you will inevitably find yourself with a mix of cloud and legacy stacks to manage. Managing the dependencies between them can cause technical issues. Having APIs to communicate between the applications in different stacks reduces the complexity, but you cannot expect these to be available in all cases.
Getting stranded due to unforeseen complexities
Unexpected technical challenges are common in software engineering, and ser‐ verless migration is no exception. A delay in the completion of one phase can cause delays in other dependent phases. This may cause tension between the teams and can lead to blaming the technology itself.
Service disruptions and unhappy customers
With a phased migration strategy, unpleasant situations can arise due to the incompatibility of services on different stacks (API protocols, data formats, pro‐ gramming languages, synchronous versus asynchronous operations, etc.). The service limits on the two sides may also differ, and it is essential to find common ground for services to mitigate service disruptions impacting customers.
Comparing Migration Strategies
Take a look at Figures 2-12 and 2-13, which compare the three strategies based on time to completion and level of risk.
Figure 2-12. Serverless migration strategies based on time to completion
Figure 2-13. Serverless migration strategies based on risk level and preference
Once you have gained knowledge of the technology, identified the appropriate work‐ loads to migrate, and charted a transition strategy, there’s one more important area to focus on. This is perhaps the most crucial factor of the ecosystem: the engineers. Their attitudes and skills will be a defining factor in the success of your organization’s serverless journey. We will complete this chapter by looking at ways to develop your knowledge base.
In some business scenarios it may be appropriate to apply a mix of strategies. Whether you take an all-at-once or phased migration approach, you may decide to retain some complex and core logic in its existing form but change the code around it to fit within the new environment. For example, suppose you are rewriting legacy logic as Lambda functions using TypeScript. However, there is a critical piece of logic originally written in C# that you prefer not to rewrite. You can use the .NET runtime for AWS Lambda with minimal changes to the event handling part of the function.
