Matilda Migrate User Guide #

Matilda Migrate Overview #

Matilda Migrate automates the migration of your existing on-premises workloads to hybrid or multi-cloud environments. Users can easily migrate applications to the cloud, optimize ongoing cloud costs with intelligent scaling, and minimize business risk from security exposures.

Matilda Migrate sets up the necessary virtual resources in minutes as well as manages deployments across multi cloud providers such as Public, Private and Hybrid. Based on the requirements, templates are created and can be customized for each application. Migrate automates and accelerates common migration scenarios in a methodical and cost-effective way.

Migration Support #

Migration is a transition from on premises infrastructure to a cloud environment. Matilda Migrate makes migration easy and supports the following migration strategies:

• Relocate – Virtualization (VMware) to the Cloud
• Rehost – Lift and Shift
• Replatform – Database Replatform / Operating System Upgrades
• Refactor – Traditional Servers (AIX/Solaris/Hp UX) –> Linux / Application Code Modification
• Repurchase – Purchase software on marketplace / from ISV’S (Splunk/AppDynamics etc.)
• Retain – Application cannot be moved to cloud, move to co-locations, or use direct connect partners to on-premise systems to reduce Latency.
• Retire – Decommission the application

How Does Matilda Migrate Support Cloud Migration? #

Matilda Migrate supports migration from on-premises or other cloud providers to AWS, Azure, GCP or the Oracle Cloud. This includes the virtual machines, migration of applications, and all of their supporting software like web servers, application servers, and database servers. Matilda Cloud makes the journey to the cloud simple, secure, efficient, and fast. Matilda Migrate accelerates cloud adoption, which in turn enables digital transformation and faster innovation for customers.

Matilda Migrate uses templates, workflows, and discovery to perform:

• Secured migration of your current infrastructure state, technology and applications with pre-built strategies, templates, and tools to address complex enterprise solutions.
• Automated actions through a workflow driven interface.
• Topology view of the entire environment.
• Modernization or containerization of legacy applications
• Reduce migration time and cost by up to 10X.
• Provides full stack deployment of infrastructure, services and applications.

List of Infrastructure Supported by Matilda Migrate #

Note: Matilda Migrate can be deployed on any Linux platforms (on premise, private-cloud, or public cloud) or any machine types (Virtual Machine or Physical Machine).

Matilda Discover #

The companion product to Matilda Migrate is Matilda Discover. Matilda Discover finds all of the applications and their supporting software in your on-premise environment, helps you decide which applications to migrate to the cloud, and then builds a database (the Discover Analysis Database in the diagram below) which contains all of the information that Migrate needs to migrate the target applications to the cloud of your choice.

Matilda Discover Architecture

Matilda Migrate Architecture #

The architecture for Matilda Migrate is shown below. The migration process starts with the data created by Matilda Discover, which is stored in the Discover Analysis Database shown below.

Matilda Migrate Architecture

Matilda Migrate Setup & Installation #

This documentation is for Matilda Migrate tool users, programmers, and DevOps engineers to use Matilda Migrate.

Information Provided by Matilda #

Matilda Cloud will provide the migration URL and the migration portal access credentials for users.

The Matilda Migrate login screen

User Interface #

All Matilda Migrate migration features can be found under the Migrate or Management dropdowns.

• The Migrate menu provides users with the UI interface required to provision and Migrate customer workloads to cloud providers.
• The Management menu is used to manage users, roles and accounts across the organization that control user access to the tool.

Migrate #

There are five different tabs under the Migrate module:

• Discover

• Plugins

• Template

• Workflow

• Wave

Workflow Screen #

Once the user has logged in to the tool, they are guided to the Workflow screen as shown below.

Matilda Migrate Workflow Screen

Discover Screen #

This tab displays all the applications that are identified by Matilda Discover for migration. This applies to customers who have used Matilda Discover to identify their applications and resources. 

Note: Customers who are not using Matilda Discover will need to upload the application details in a JSON document.

The Discover Screen

Applications, Topology & Resources #

• Each of the applications that are displayed under the Discover tab are promoted to migration from Discover or by using the application configuration JSON document uploaded by the user.
• Clicking on the application provides meta-information about the source hosts and services running on each of those instances.

The Topology screen provides high-level information about the discovered applications and the targeted services on the cloud that can be provisioned to migrate the source applications and services.

Application Topology view

Each application has a Topology view and Resources view as shown below.

Application Resources view

The Resources screen provides detail-level information about the application. Use this screen to link to the templates on the Template screen, which can be utilized to migrate the applications.

The Resources screen inside a Workflow

Plugins #

Purpose:  This tab displays all the supported providers, plugins, and services that are offered by Matilda Migrate.

The Plugin Screen

Plugin Features #

Each of the plugins individually lists information about all supported services and their respective providers.

For instance, clicking on the GCP plugin will list the complete set of services supported by GCP. The user can modify or construct new templates to support their unique requirements. Templates can also be versioned to support growing application complexity requirements.

The user can add new services under each provider, or the existing services can be modified based on the user’s needs. 

Adding new plugins

New services can be added by clicking on a cloud provider and clicking the Service button as shown above.

Adding new plugins

Newly created plugins can be published using the Publish button. Published plugins will appear on the plugin screen.

Enabling and disabling the plugins

Additionally, services can be enabled and disabled by clicking on the blue toggle button on right corner of each plugin.

Importing and exporting the plugins

Apart from creating new plugins, users can import or export plugins as zip files. This feature is useful when you already have a set of plugins ready to be deployed into the new or existing environment.

For ease of use and accessibility, customers have the flexibility to add their most used providers as favorites. These providers appear at the top of the Plugin screen under the Favorites bar. In the screenshot below, we have added some cloud providers as favorites, hence they are shown on the top under the favorites section.

Favorites in the Plugin screen

Template #

The Templates tab displays all the supported predefined templates that are offered by Matilda Migrate.

Templates are groupings of resources designed to achieve the desired service architecture for any cloud provider. These can consist of:

• High-availability networking components.
• Two-tier backend and frontend applications.
• Load balancers.
• R53 hosted zone setup.
• Database migration templates for replatforming.

The Template screen

Template Features and Adding Templates #

Matilda Migrate provides industry standard best practices templates for users. Users also have the flexibility to create new templates based on their application migration needs.

Users can add new templates using the +Template icon on the top right corner of the template section.

Adding new templates

Services for new templates can be added by combining existing templates using import features, or new groups can be created to add resources that are not part of the predefined templates. Users can add new template tasks in existing templates, or import new tasks by clicking the three dots in the top right corner of the template and clicking Import. Users can also create new resources, including new groups, that are not part of the predefined templates. Using templates, cloud architects can construct the best practices for their environment.

Importing templates

Each group consists of a logical collection of tasks. These tasks correspond to the services of each provider. 

In the example below, groups ‘Resource Group’ and ‘Network’ exist under the Azure MSSQL DB template.

Groups under each Application

Tasks under each group can be expanded or collapsed using the toggle button on the right.

Adding new groups

To add new tasks under groups, click +Create New Task at the bottom of each group. Inputs must be provided under the General and Input tabs for each new task.

The General tab includes inputs that are related to the provider. The Input tab contains inputs to the service selected under the General tab.

Expanding the Task view

Accounts must be added to workflows to schedule them for running. Workflows, when created by importing the templates, also import the accounts attached to them to help to authenticate the new cloud provider. The accounts used by the services in the template should be selected using the Accounts button on the top left corner. To select accounts used by each service, click the add button next to Accounts. One or more accounts can be selected and set to default, as shown in the image below. Note that although a template can be associated with multiple accounts, a task can only be mapped to a single account.

Adding accounts to the template

The account can also be added at the task level by clicking on each task. It opens the General tab where the user can add accounts by clicking on the Account button highlighted below.

Adding Accounts to a single task

In order to default a specific account to all tasks at once, check the account and toggle-on the Default button. Using the click to add Account button single or multiple accounts can be checked and assigned to different providers present in the template/workflow.

Setting Account to as a default

Adding accounts to task can be done in one of the two following ways:

• All tasks can default to one specific account using the Accounts button on the right-hand corner of the screen.
• Click on a specific task and select an account from the drop down under General > Account. The account should now be selected on the Template/Workflow level for the account list shown there.

Info tab of a task

The Info tab on each task displays the description of each task, and lists the inputs the user needs to give and the outputs they receive prior to loading the inputs or scheduling the workflow.

Input tab of a task

The Input tab lists out all the inputs the user needs to fill. It opens up with the default values which can be configured according to the infrastructure design.

Output tab of a task

The Output tab lists out all the outputs from a task after we schedule the workflow for a run. Also, in the template screen it shows the default output values.

Workflow #

Workflows are used for the provisioning and migration of resources to the cloud. Workflows are composed of single or multiple templates that can be imported from predefined templates. In addition to importing templates, users can add any missing tasks to workflows. Once the workflows are ready, they can be executed. Executing workflows results in the provisioning and migration of resources.

Each workflow corresponds to a single application or combination of applications based on their dependencies.

To navigate to workflows, click the Workflow window in the migrate menu.

The Workflow screen

Workflow Features #

Templates created in the previous section can be imported into workflows before they are executed.

Workflows can be created either manually by clicking on +Workflow on the top right corner of the screen, or they can be cloned from existing workflows.

Workflow Cloning #

Cloning lets users create an exact copy of an existing workflow. This can be done by opening an existing workflow and clicking on the three dots on the top right corner and selecting Clone. This will create a workflow in the home screen of the workflow as shown, which can be opened and modified based on the user’s needs. This saves the user time when creating the same workflow multiple times for different needs.

Cloning of the existing workflow

Options for cloning of the existing workflow

The Topology view for a selected workflow

The Resources view for a selected workflow

Favorite Workflows

Importing a template into workflow

Templates created in the previous section can be imported into workflows before execution.

The groups, tasks, accounts, and inputs work similarly to templates. Once the workflows are created and templates are imported, any additional groups and tasks are created with necessary inputs. 

Workflow Scan #

Workflows can be scanned prior to scheduling in order to verify that the infrastructure does not contain any security or compliance issues. Scanning workflows checks for any misconfigurations and generates a report. The latest scan results can be viewed in the Compliance tab on the workflow screen.

Scan button of a workflow

The workflows can be scheduled to connect to the cloud provider and begin creating resources for each task in the specified account. In order to schedule the workflows, all the tasks under each group should be in a configured status. All groups and workflows should be marked as Configured as shown below.

Scheduling the workflow

Workflow Topology #

The Topology screen provides the topological view of the workflow as shown below.

Topology view of the workflow

 Workflow Resources #

The Resources screen provides the generic view of the workflow as shown below.

Workflow Compliance #

The Compliance screen lists all the scan results performed by the user and also gives the results of each task from a workflow or a template.

The Compliance tab for a selected workflow

Workflow History #

The History screen lists all the actions performed by the user and gives the status of each task.

History tab for a Workflow

Workflow Sync #

Sync feature of workflow

The above feature helps in syncing two different versions of a workflow and merge the changes.

Workflow Environment #

The Environment screen gives the topological view of various environments set up for the workflow by the user.

Environment tab in a workflow

Workflow Logs & Files #

Logs of corresponding workflows can be viewed in the output section of each task as shown below. Clicking on each task opens up the information pane on the right hand side of the screen.

Viewing logs, errors, and output

The files can be viewed or modified as shown below.

The File view of Template

The Workflow screen includes a Generate button to perform file generation on a container. Once the workflow is created, use the generate button to create tasks or services related to template files on the docker container.

Generate button on workflow screen

View of the Generate window on the workflow screen

Scan results at task level part1

Scan results for each task can be viewed by clicking on the highlighted button above which is present right to each task. Upon clicking it, the results open up as shown below. They are also available for download by clicking on the button shown below to the right of Anomalies.

Scan results at task level part2

Wave #

A wave is an identified group of servers, virtual machines, containers, or applications to be migrated in the same time period. Migration waves define the state of applications and their managed services and migration methods for reaching the target state.

 The Wave screen

Inside a Wave group

Management #

There are three tabs under Management:

• User

• Account

• Role

User #

Navigation: Management > User

The User tab displays all the user accounts that exist in the Matilda Migrate platform.

Use the User tab to manage users’ authentication and authorization for Matilda Migrate access.

The User screen

Account #

Navigation: Management > Account

The Account tab displays all the accounts associated with the system. Accounts are grouped by providers, and each provider can have multiple accounts associated with it.

The Account screen is used to manage account credentials, for example, AWS account credentials, GCP account credentials, SSH keys, Jira and Email accounts etc.

New accounts can be onboarded or deleted.

The Account screen

The Account addition and deletion

Role #

Navigation: Management > Role

The Role tab displays all the existing roles and permissions that are associated with the respective roles. Roles can have different sets of permissions that control user access. The user can modify each role in order to add or remove additional permissions.

The Role screen is used to administer user’s authentication and authorization to access the tool.

The Role screen

Use Cases #

Matilda Migrate uses Terraform, Shell Scripting and Ansible to create various standard cloud configuration templates for the migration of various resources described below to the desired cloud provider.

Terraform reduces the manual effort and helps to automate the resource provision for various cloud providers. Matilda Migrate uses Terraform to create the templates that build cloud infrastructure with Infrastructure as Code.

Migrating an On-Premise K8 Cluster to GKE #

GKE (Google Kubernetes Engine) is a fully managed K8 (Kubernetes) service. It provides advanced cluster management.

The workflow below describes the process for migrating an on-premise K8S cluster to a Google managed GKE.

 1. Creating the Network

 2. Creating the Subnet

 3. Creating the Container Registry

 4. Creating the GKE cluster

 5. Creating the Nodepool

 6. Creating the on premise K8S copy

 7. Migration of the on Premise K8 cluster to GKE

 8. Deployment of NGINX with a Helm Chart

 Workflow of migrating to GKE

This workflow creates a GKE cluster in the Google cloud and migrates the on-premise Kubernetes cluster into the newly created GKE cluster.

Migrating an on-premise K8 cluster to EKS #

Amazon EKS (Elastic Kubernetes Service) is a managed container service to run and scale Kubernetes applications in the cloud or on premise.

The workflow below demonstrates the process for migrating an on premise K8S cluster to AWS EKS.

 1. Creating IAM Role for cluster

 2. Creating role-policy for cluster

 3. Creating IAM Role for Fargate

 4. Creating role policy for Fargate

 5. Creating EKS Cluster

 6. Creating Fargate Profile

Migration to an AWS EKS workflow

Landing Zones #

Landing Zones standardize your cloud infrastructure. They provide a baseline for resource organization, policy management, identity, and access control.  The image below shows a landing zone created by Matilda Migrate with the following workflow tasks.

 1. Creating Organization

 2. Creating the Projects

 3. Creating the Database Instance

 4. Creating the GKE Cluster

 5. Setting up the Landing Zones

 6. Migrating the Containers

Landing zone workflow-Part1

Landing zone workflow-Part2

Landing zone workflow-Part3

JAVA (Spring Boot) Application Migration to GCP #

The workflow below assists in migrating a Spring Boot application from on premise to the GCP. It ensures the creation of an instance in GCP and the copying and deployment of the Spring Boot application.

 1. Creating GCP Compute instance

 2. Copy Spring Boot App from Source Server

 3. Deploy the App into newly created instance

Spring Boot application migration to GCP workflow

Windows IIS Migration #

The workflow below migrates a windows application from a Windows 2016 server to a Windows 2019 server in GCP. The tasks included in the workflow are mentioned below:

 1. GCP Compute Instance

The Windows to GCP app migration workflow

Application Server Migration #

The below template assists in automating the migration of multiple on-premise Linux servers to the AWS cloud. It uses the public IPs of the on-premise servers, the username, and the PEM key to migrate the servers in the desired region. The template below describes the Replicate, Launch and Cutover process – all the stages of an AWS migration – to help users replicate multiple on-premise servers at one time. There are three tasks in AWS MGN

 1. Replicate

 2. Launch

 3. Cutover

AWS MGN Template

Migration of a Microsoft SQL Server to AWS RDS #

This workflow describes the migration of a Microsoft SQL server to AWS RDS (Relational Database Service).

 1. Creating AWS MSSQL RDS Instance

Workflow to migrate MSSQL to RDS

The following image shows the workflow of Terraform Infrastructure as Code to spin up the RDS instance from the Matilda workflow screen. Note the inputs provided by the user below.

Using Terraform to spin up AWS RDS-Part1

Using Terraform to spin up AWS RDS-Part2

Migration of a Microsoft SQL Server to GCP #

The workflow in the image below demonstrates the creation of GCP MSSQL database creation from the workflow screen.

 1. Creating the GCP MSSQL Database Instance

 2. Creating the GCP MSSQL Database

Workflow to migrate SQL to GCP

Spinning Up Resources Using Terraform Infrastructure as Code #

Terraform Infrastructure as Code automates the process of spinning up resources in the cloud environment (AWS/Azure/GCP/OCI). Matilda Migrate uses Terraform to create the templates that automate cloud infrastructure building. Matilda Migrate automatically generates the Terraform Infrastructure as Code required to provision the cloud resources needed to support your applications in the cloud.

Terraform templates are stored in the Plugins screen as shown below. These can be used to create workflows from the Workflow screen.

The Plugin screen

Selecting one of the options from the Plugin screen opens a list of plugins available for the cloud provider. The plugins are created using Terraform templates, Shell scripting and Ansible.

Automatically generated Terraform plugins

The image below shows the usage of plugins on the workflow screen. To access a plugin as a service in a workflow, the user needs to enable the desired plugin on the Plugins screen.

Using a Terraform plugin in a workflow

The user will be able to access the Terraform code from the Stack tab as shown in the image below. The user will be able to modify the files and save their version for a particular workflow.

The Stack tab from the Workflow screen

Modernization #

Once applications and their infrastructure are discovered by Matilda Discover they appear on the Discover screen in Matilda Migrate, the Action tab which can be found after clicking on a application can be used to generate templates or workflows. The example below shows modernization of an Oracle on-premises VM-based database to PAAS (Oracle RDS).

Discovered applications in Matilda Migrate

Action tab inside a discovered Application

The Topology view of a database migration

The Resources view of database migration

Hitting the Migrate button initiates automated migration of the database.

Details of database migration

Support #

Matilda Cloud support is offered by email during working hours Monday-Friday.

Please contact info@matildacloud.com for assistance.