When trying to evaluate the next state
of an application, you need to do an
application rationalization exercise.
There are many articles and blogs that explain common architecture patterns
and suitability for a certain platform and what the migration patterns are. In
this article, we will expand on how to evaluate suitability, and dig deeper into
the six Rs to explain the logic of why an application may be more suited to a
specific pattern.
What Are Migration Patterns?
When an application is to be moved from its current state, migration patterns
describe which components of an application need to change (hardware, OS,
platform/stack, application code, architecture). If you are looking at many
applications, migration patterns are also a way to group applications into cat-
egories according to the areas of change, to make it easier to address the appli-
cations collectively.
As a primer, we use Figure 1 to explore what each of the patterns generally
mean for an application. If an application is to be migrated from its current
state to a new home, various layers of the application may undergo change. For
example, a replatform migration pattern will mean that the application is
undergoing a change all the way from its current hardware platform to the
application and data stack. Examples include:
• From Oracle database on Windows Server to Amazon RDS
• From Java application running on WebLogic to AWS Elastic Beanstalk
The application functionality, configuration, code and underlying architecture
will remain unchanged.
Architecture Layer, Stack Where Changes are Required
Migration
Patterns
Hardware and
OS Image
App, Data Stack
App Config and
App Code
Rehost
Replatform
Refactor,
Replace
Figure 1: Migration Pattern Requirements
22 | THE DOPPLER | FALL 2018
App and Data
Architecture