Matilda Migrate Users Guide

What is Matilda Migrate? #

Matilda Migrate automates the migration of your existing on premise workloads to hybrid or multi-cloud environments. Businesses 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.

What does Matilda Migrate do? #

Matilda Migrate supports migration from on premise or other clouds to AWS, Azure, GCP or the Oracle Cloud. This includes the virtual machines, and migration of applications and all of their supporting software like web servers, application servers, and database servers. Matilda Cloud makes journey to the cloud simple, secured, efficient and fast, thus accelerating 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.
  • Modernize or containerize 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 #

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.,
Databases 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 Migrate Overview #

Migration is a transition from on premises infrastructure to a cloud environment. Matilda Migrate follows certain strategies to easily migrate to the cloud. Below are migration strategies that are supported by Matilda Migrate.

  • Relocate – Virtualization (VMware) to the Cloud
  • Rehost – Lift and Shift
  • Replatform – Database Replatform / Operating System Upgrades
  • Refactor – Traditional Servers (AIX/Solaries/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 to reduce Latency.
  • Retire – Decommission the application

Matilda Migrate can be deployed on Linux Platforms hosting provider (on premise, private-cloud, or public cloud) or Instance Type (Virtual Machine or Physical Machine).

A user account with the root permissions should be created on the server. Enable switching to root context with no password authentication on Matilda Server.

Matilda Discover Architecture #

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 DB 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 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 DB shown below.

Matilda Cloud Migration Architecture

Matilda Migrate Architecture

Getting Started with Matilda Migrate #

 

Purpose #

This documentation is for Matilda migrate tool users, programmers, and DevOps Engineers to be able to use Matilda Migrate.

Accessing the Migration portal #

Use the Admin Credentials provided by Matilda to log in to the Migration console.

The Migration URL #

Https: https://<Matilda-migrate-URL>

Migrate Logon Screen

The Matilda Migrate login screen

 

 

The Initial Workflow Screen #

Once the user has logged into the Tool, he would be guided to the Workflow Screen as shown below.

Migrate Initial Workflow Screen

Matilda Migrate Workflow Screen

Top Level Matilda Migrate User Interface #

The Hub and Management are the two broad categories that all the Migration features fall into.

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

 

Hub #

There are six different tabs under the Hub:

  • Discover
  • Plugins
  • Template
  • Workflow
  • Wave

 

Discover #

Purpose:  This tab displays all the Applications that are identified by Matilda Discover to be promoted to migration.
Note: This applies to customers who are have used Matilda Discover to identify their application and their resources. Customers who are not using Matilda Discover will need to upload the Application details in a json document.

Navigation: Hub > Discover #

Migrate Discover Screen

The Discover Screen

Features #

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

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

Workflow Resources View

The Resources view for a Workflow

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

Application Topology View

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

Resources Inside a Workflow

The Resources screen inside a Workflow

Plugins #

Purpose:  This tab displays all the supported Providers, Plugins, and Services that are offered by the Migration tool.

Navigation: Hub > Plugin #

Top Level Plugin Screen

The Plugin Screen

Features: #

  • Each of the plugins individually lists information about all the supported services by the respective providers.
  • For instance, clicking on GCP provider will list the complete set of services supported by GCP. These templates can be modified to support individual customer requirements and can be versioned.
  • New services can be added under each provider, or the existing services can be modified based on the customer’s needs.

Enabling and Disabling Plugins

Enabling and disabling the plugins

Additionally, services can be enabled and disabled by click on the blue toggle button above.

For ease of use and accessibility, customers have the flexibility to add their most used providers as favorite. These providers will show up on the top under the favorites bar. In the screen shot below we have added some of cloud providers as a favorites hence they are shown on the top under the favorites section.

Favorite Plugins

Favorites in the Plugin screen

Templates #

 Purpose:  This tab displays all the supported predefined templates that are offered by Matilda Migrate.

Templates are grouping 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.

 

Navigation: Hub > Template #

Main Template Screen

Main Template screen

Features #

  • Matilda Migrate provides industry standard best practices templates to be utilized by customers.
  • Additionally, customers also have the flexibility to create new templates as per their Application Migration needs.

New templates can be added using the +Template icon on the top right corner.

Adding New Templates

Adding new templates

 

Services for new templates can be added by combination of existing templates using import feature or new groups can be created to add resources that are not part of the predefined templates.

Importing Templates

Importing templates

Each group is a logical collection of a set of tasks, these tasks represent the services under each provider. In the below example Virtual Private Cloud, Grp-Public and Grp-Private are all groups. Each group has a set of tasks that represent a specific cloud service.

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

Adding New Tasks to a Template

Adding new tasks

New tasks can be added under groups by clicking on +Create New task at the bottom of each group. Inputs needs to be provided under general and Input tab for each new task.

The General tab consists of inputs that are related to the provider and Inputs tab contains inputs to the service selected under the General tab.

Expanding the Task View

Expanding the Task view

Adding accounts to templates – Accounts used by the services in the template should be selected using the Accounts (Change) button on the top left corner.

A specific template can have tasks that use single or multiple accounts. To select multiple accounts for a template, check all the accounts that are needed. Note that though a template can be associated with multiple accounts, a task can only be mapped to a single account.

Adding Accounts to a Template

Adding Accounts to a Template

In order to default a specific account to all tasks at once, check the account and click on the default button.

Adding accounts to Task – Accounts can be done in two 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, Under General à Account, select an account from the drop down. Note that the account should be selected on the Template level for the account list to be shown here.

 

Workflow #

Purpose:  This section consists of workflows that are used for actual Provisioning and Migration of resources to the cloud.

  • Workflows are comprised of single or multiple templates that can be imported from the predefined templates. In addition to importing the templates, we can add any missing tasks to workflows. Once the workflows are ready, they can be executed. Execution of workflows results in provisioning and Migration of resources.
  • Each workflow can represent single application or combination of applications based on their dependencies.

 

Navigation: Hub > Workflow #

Hub Workflow

The Workflow Screen

Features: #

  • Templates created in the previous section can be imported into workflows before execution.
  • Workflows can be created by either manually by clicking on +Workflow on the top right corner of the screen or they can be cloned from existing workflows.
  • Cloning – Lets users create an exact copy of an already existing workflow with a Random Name. This can be done by opening an already existing workflow and clicking on the three dots on the top right corner and cloning it as shown below. This would create a workflow with a Random name in the home screen of the workflow as shown, which can then be opened and modified as per customer needs. This saves customers a lot of time when creating the same workflow multiple times for different needs.

Resources for a Selected Workflow

The Resources for a Selected Workflow

 

Favorite Workflows

Favorite Workflows

Importing a Template into a Workflow

Importing a template into workflow

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

Groups, Tasks, Accounts, and Inputs to each of these works very similar to the way templates work.

Once the workflows are created, and templates are imported, any additional groups and tasks are created with necessary inputs. The workflows can be scheduled. 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.

Scheduling the workflow will connect to the cloud provider and start creating the resources in the specified account for each task.

Scheduling the Workflow

Scheduling the workflow

 

Cloning of a workflow can be done by utilizing Clone button on the top right corner. We can clone a workflow into workflow form or template form as shown in the below diagram. This creates a new clone of the workflow with or without the information on accounts based on user inputs.

Cloning a Workflow

Cloning a workflow

The topology screen gives the topological view of the workflow as shown below.

Topology View of a Workflow

Topology view of the Workflow

 

The History tab lists all the Actions performed by the user and gives the status of the task.

History Tab for a Workflow

History tab for a Workflow

 

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

Environment Tab for a Workflow

Environment tab in a Workflow

 

Logs of corresponding workflows can be viewed in the output section as shown below.

Workflow Logs and Errors

Viewing logs, errors, and output

 

The files can be viewed or modified as show below:

File View of a Template

The File view of Template

The Migrate screen provides a Generate button where it can perform file generation on a container. Once the workflow is created, we can use the generate button to create the tasks or services related to template files on the Docker container.

Workflow Generation

Generate button on workflow screen

 

Wave #

 Purpose:  A wave is an identified group of servers, virtual machines, containers, or applications to be migrated in the same time period. Application dependencies are indicated by lines. Migration wave defines the state of applications, their managed services, and the migration methods to reach the target state.

Navigation: Hub > Wave #

A Wave Group

A Wave Group

Management #

 There are four tabs under Management:

  • User
  • Attribute
  • Account
  • Company
  • Role

 

User #

 Purpose:  This tab displays all the user accounts that exist in Matilda Migration platform.

This is used to administer user’s authentication and authorization to access Migrate.

Navigation: Management > User #

Migrate User

The User Screen

Attribute #

Purpose:  This tab displays all the existing system permissions. The attributes cannot be modified or deleted.

This screen will be available only for the super admins to view all the available permissions.

Navigation: Management > Attribute #

Attributes

The Attribute screen

Account #

Purpose:  This tab displays all the accounts associated with the system. Grouped by providers, each provider can have multiple accounts associated with it.

This screen will be used to manage account credentials. E.g. AWS account credentials, GCP account credentials, SSH keys, Jira and Email accounts etc.

New accounts can be onboarded or deleted.

 

Navigation: Management > Account #

Accounts

The Account Screen

Company #

Purpose:  This tab displays all the companies associated with the system.

This screen will be used to manage company details – Name, Description, Primary Contact etc.

Navigation: Management > Company #

Company

The Company Screen

Role #

Purpose:  This tab displays all the existing roles and permissions (Attributes) that are associated with the respective roles. The roles can have different set of permissions which will control the access to the user. Each role can be modified to add or remove additional permissions.

This is used to administer user’s authentication and authorization to access the tool.

Navigation: Management > Role #

Roles

The Role Screen

Use Cases #

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

Terraform reduces the manual effort and helps in automating the resource provision on various cloud providers. Matilda Migrate uses Terraform to create the templates which build cloud infrastructure with infrastructure as code.

Migrating an On Premise K8 Cluster to GKE #

 Google Kubernetes Engine service is a fully managed Kubernetes service. It provides advanced cluster management.

Below is the workflow describing the process for migrating on premise K8S cluster to Google cloud managed GKE. The workflow consists of the following tasks:

  • Creating the Network
  • Creating the Subnet
  • Creating the Container Registry
  • Creating the GKE cluster
  • Creating the Nodepool
  • Creating the on premise K8S copy
  • Migration of the on Premise K8 cluster to GKE
  • Deployment of NGINX with a Helm chart

Migrating On Premise K8 Cluster to GKE

Migrating to GKE Workflow

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 #

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

Below is the workflow describing the process for migrating an on premise K8S cluster to AWS EKS.

Migrating an On Premise K8 Cluster to AWS EKS

Migration to an AWS EKS Workflow

Landing Zones #

The purpose of landing zones is to standardize your cloud infrastructure. It provides a baseline for resource organization, policy management, identity, and access control.  The image below shows a landing zone created by Matilda Migrate.

The workflow implements the following tasks:

  • Creating organization
  • Creating the projects
  • Creating the database instance
  • Creating the GKE cluster
  • Setting up the Landing Zones
  • Migrating the containers

Cloud Landing Zone Part 1

Landing zone workflow-Part1

 

Cloud Landing Zone Part 2

Landing zone workflow-Part2

 

JAVA (Springboot) Application Migration to GCP #

This workflow assists in migrating a Spring Boot application from on premise to the GCP. It takes care of creating an instance in GCP and copying and deploying of the Spring Boot application.

Migrate Spring Boot Application to GCP

Spring Boot Application Migration to GCP Workflow

Windows IIS migration #

The workflow below migrates a windows application from a Windows 2016 server to Windows 2019 server in GCP.

Migrate Windows Application to GCP

Windows to GCP App Migration workflow

 

Application Server Migration #

The below workflow assists in automating the migration of multiple Linux servers from on premise to the AWS cloud. It uses the public IP’s of the on premise servers, username, and PEM Key to migrate the servers in the desired region. The workflow 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.

Linux Application Server Migration to the Cloud

Workflow for a Linux Application Server Migration

 The image below shows the migration of three Linux servers. The input tab provides the inputs that the user is expected to give at the time of workflow scheduling.

Linux Application Server Migration to the Cloud Details

Input tab of the Migrate workflow for 3 Linux servers

The output of the workflow is the replicated IP’S in the desired region with the given configuration. It also provides with the instance ID’s as shown in the below image.

Linux Application Server Migration to the Cloud Outputs

Output tab of Migrate Workflow

 Here is the image of the AWS console showing the replicated servers along with the ids that are given out as output in the previous image.

Migrated Servers in the AWS Console

 

Replicated Servers on the AWS Console

 

The above example shows the migration of Linux servers. This service can also be used to migrate windows servers (single or multiple).

Migration of a Microsoft SQL Server to AWS RDS #

This workflow describes workflow to migrate a Microsoft SQL Server to AWS RDS.

Migrate SQL Server to AWS RDS

Workflow to Migrate MSSQL to RDS

 

This workflow uses Terraform infrastructure as a code to spin up the RDS instance from Matilda workflow screen. The inputs provided by the user are shown in the below images.

Using Terraform to Spin Up AWS RDS

Using Terraform to Spin up AWS RDS-Part1

User Customization of Terraform Code to Spin Up AWS RDS

User Customizations of Terraform Code to Spin Up AWS RDS

Migration of a Microsoft SQL Server to GCP #

This workflow describes the creation of GCP MSSQL database creation from the workflow screen.

Migrate MS SQL Server to GCP

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 which automate the building of the cloud infrastructure. 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 Plugins Page

The Plugin Screen

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

Automatically Generated Terraform Templates

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

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 in a Workflow

The Stack tab from the Workflow Screen

Modernization #

Once applications and their infrastructure are discovered by Matilda Discover, and appear on the Discover screen in Matilda Migrate, the Action Tab can be used to generate templates or workflows. The following example shows modernization of an Oracle on premise VM based database to PAAS (Oracle RDS).

Discovered Applications in Matilda Migrate

Discovered Applications in Matilda Migrate

Topology View of a Database Migration

The Topology view of a Database Migration

 

The Resources view of Database Migration

Hitting the Migrate button initiates automated migration of the database.

The Action tab on the Discover screen

Support #

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

Please contact info@matildacloud.com for assistance.

Powered by BetterDocs