General Concepts » Migrations


When considering applications for a migration to IaaS services in public cloud it may be necessary to "migrate" a server to the target environment in order to deliver an application.  This process of "migration" may involve re-installing a new host or moving the host with a "lift/shift" approach wher the state is preserved.  Regardless of the method the application, the original servers will be decommissioned, replaced by the newly migrated servers.

Consider the Application Service Support System (SSS).  It is Implemented on-premises on a series of four servers: TESTCOPVA06, TESTCOPVA12, TESTCODVD02 and TESTCODVA05.  A decision to migrate this application to IaaS is made in the Planner tool in 2019Q1 in the AWS Scenario.  When this plan is implemented cloudstep will create a new Implementation called IaaS Service Support System (SSS) (AWS Scenario).  It will then create the "_aws' equivalent model elements (as Cloud Services).  They will have the same name as the original server with the suffic _aws (or _azr if Azure is the target IaaS environment).  To do this, it uses the instructions you've given it as to how to price these servers (server type, licensing inclusion, family of server, etc.).  If any of these servers already exists and is used in another Application Implementation then it will be attached to this newly created implementation.

How does know how to price the migrated servers?

The answer to this is that it doesn't unless you tell it how to.  In fact if you don't tell it how to migrate the server it won't migrate it at all.  This is useful if there are servers you plan to retire in the future and don't want to migrate at all.

cloudstep uses the Infrastructure Planning tool to do this.  A series of EC2 Costs or Azure VM Costs must be created and various VMs sorted and categorised in order for it to know how to migrate the server.