Matilda Migrate User Guide

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).

Feature Category Versions (Minimum version & All higher versions are supported)
Operating Systems


Linux Ubuntu 12.04+, RHEL 5+, CentOS 5+, Oracle Enterprise 5+
Windows Windows 2003 Server – Windows 2019
Application Services Web, App, Proxy WebLogic 10.3+, WebSphere 8.0+, IIS 7+, JBoss 9+, Tomcat 7+, Nginx 1.1+, zookeeper 3.4+, Solr 7+, Kafka 2.0+, BizTalk 2013+, RabbitMQ 3.5+, Hadoop Ecosystem, Kubernetes, iPlanet etc.,


RDBMS Oracle 10+, MySQL 5.7+, MSSQL Server 2008+, DB2 11+, PostgreSQL, Cassandra, MariaDB etc.,
Other MongoDB 1.6+, Influx DB, Elasticsearch, Hadoop Ecosystem, etc.


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 for assistance.


Powered by BetterDocs