- What is Matilda Migrate?
- What does Matilda Migrate do?
- Matilda Migrate Overview
- Matilda Discover Architecture
- Matilda Migrate Architecture
- Getting Started with Matilda Migrate
- Top Level Matilda Migrate User Interface
- Use Cases
- Migrating an On Premise K8 Cluster to GKE
- Migrating an on premise K8 cluster to EKS
- Landing Zones
- JAVA (Springboot) Application Migration to GCP
- Windows IIS migration
- Application Server Migration
- Migration of a Microsoft SQL Server to AWS RDS
- Migration of a Microsoft SQL Server to GCP
- Spinning up Resources using Terraform Infrastructure as Code
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 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 Migrate Architecture
Getting Started with Matilda Migrate #
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 #
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.
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.
There are six different tabs under the Hub:
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 #
The Discover Screen
- 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.
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
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.
The Resources screen inside a Workflow
Purpose: This tab displays all the supported Providers, Plugins, and Services that are offered by the Migration tool.
Navigation: Hub > Plugin #
The Plugin Screen
- 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 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.
Favorites in the Plugin screen
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
- 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
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.
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
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
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
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.
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 #
The Workflow Screen
- 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.
The Resources for a Selected 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
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
The topology screen gives the topological view of the workflow as shown below.
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
The Environment tab gives the topological view of various environments set up for the workflow by the user.
Environment tab in a Workflow
Logs of corresponding workflows can be viewed in the output section as shown below.
Viewing logs, errors, and output
The files can be viewed or modified as show below:
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.
Generate button on workflow screen
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
There are four tabs under Management:
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 #
The User Screen
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 #
The Attribute screen
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 #
The Account Screen
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 #
The Company Screen
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 #
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 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.
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
Landing zone workflow-Part1
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.
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.
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.
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.
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.
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.
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.
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-Part1
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.
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 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 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
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
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
Matilda Cloud support is offered by email during working hours Monday-Friday.
Please contact firstname.lastname@example.org for assistance.