Matilda Cloud
Self-Service Migration Platform
Product Overview & Operational Guide
1. What Is Self-Service?
A self-service product enables an intended user — such as a cloud architect, application owner, or migration engineer — to complete an end-to-end job without requiring manual intervention from the vendor. This includes onboarding, configuring access, running migrations, interpreting results, and operating the run-time dashboard — all through a guided UI and/or API.
The platform provides automation, guardrails, and clear status feedback throughout every stage of the migration lifecycle. Self-service does not eliminate support; it minimizes the required human touch. Assisted service remains available as an optional lane for complex edge cases.
2. Migration Pipeline
The self-service workflow follows a structured five-stage pipeline:
Setup Cloud Configurations | → | Install Agent | → | Block-Level Replication | → | Testing | → | Cutover |
Stage Descriptions
- Authentication – Roles and permissions, user profile setup, and agent installation.
- Configuration – Cloud profile, replication and launch settings, network communications, and source environment (account group) configuration.
- Replication – Initial full sync followed by continuous incremental sync.
- Testing – Launch a test instance and validate workloads before cutover.
- Cutover – Clean up resources, shut down the source environment, and bring up the target.
Applied Self-Service Capabilities
For both on-premises → cloud and cloud → cloud migrations, users can independently:
- Securely connect source environments
- Configure tool access for source and cloud environments
- Perform migration activities — agent install, replication initiation, test instance launch, and cutover
- Benefit from encryption in transit (TLS) and at rest; migration data never leaves the customer estate — only migration metadata is processed
- Leverage full audit logs for compliance requirements
3. Principles of True Self-Service
The following principles define what a genuinely self-service migration platform delivers:
Principle | What It Means |
|---|---|
Frictionless Onboarding | Easy setup of source and target environments, agent deployment, and migration Apps/Waves creation with minimal manual configuration. |
Automation by Default | Automated migration Server/Apps creation, initial sync/incremental synchronization, and retry mechanisms with idempotent operations. |
Guided Decisions | Migration readiness messages, right-sizing recommendations, and bandwidth estimation built into the workflow. |
Transparency | Real-time migration dashboards, replication status, progress tracking, migration logs, and error logs. |
Safe & Governed | Role-based access control (RBAC), audit trails, secure credential management, encrypted data transfer, tenant isolation, and compliance-aligned processes. |
Operationally Reliable | Automated monitoring, replication health checks, error handling, throttling/rate-limit management, recovery workflows, and resilient migration execution. |
Exportability | Downloadable agent installation logs, replication logs, and orchestration logs for full operational visibility. |
4. Self-Service Migration Checklist
Use the checklist below to ensure all migration phases are addressed before, during, and after execution. Items marked High severity are critical path; Medium severity items should be addressed to avoid post-migration issues.
Phase | Checklist Item | Details | Severity |
|---|---|---|---|
Pre-Migration | Identify application dependencies | Map all upstream/downstream systems | High |
Pre-Migration | Validate OS compatibility | Ensure Linux/Windows supported on cloud provider | High |
Pre-Migration | Assess VM sizing | Right-size compute capacity | Medium |
Pre-Migration | Check licensing (Windows/SQL) | Validate BYOL or included | Medium |
Network | Design VPC and subnets | Avoid IP conflicts | High |
Network | Enable necessary ports | Communication between source, target and Matilda tool | High |
Network | Validate security groups | Ensure required ports are enabled | High |
Migration | Set up Matilda Rehost module | Prepare source and target environment for migration | High |
Migration | Run test migration | Validate workloads | High |
Migration | Validate data consistency | No data loss | High |
Migration | Plan cutover | Minimize downtime | High |
Post-Migration | Verify application functionality | End-to-end tests | High |
Post-Migration | Check performance | Monitor resources | Medium |
Post-Migration | Enable monitoring | Set up required monitoring tools as per cloud standards | High |
Post-Migration | Set up backups | Snapshots/backup policies | High |
Post-Migration | Optimize costs | Savings plans | Medium |
Post-Migration | Decommission on-premises | Avoid duplicate cost | Medium |
5. Platform Capabilities & Compatibility
Matilda Cloud supports the following environments, operating systems, and migration targets:
Capability | Coverage | Status |
|---|---|---|
Migration Scope | On-Prem → Cloud, Cloud → Cloud, Multi-Region, Multi-Environment (Dev, QA, UAT, Prod) | Supported |
Cloud Targets | AWS, Azure, GCP, and OCI | Supported |
Architecture | 64-bit Windows and Linux servers | Supported |
Windows OS | Windows Server 2012–2025, Windows 8/10/11 | Supported |
Linux Distributions | Ubuntu, RHEL, CentOS, Oracle Linux, Debian, SUSE, Rocky Linux | Supported |
6. Frequently Asked Questions
Q: The current installation and onboarding process relies heavily on manual steps, leading to frequent pre-check failures, delayed VM readiness, and dependency on Matilda staff. How is this addressed? The end-to-end onboarding workflow is structured into 13 clearly defined steps, with ownership and tooling assigned at each stage. The table below outlines the full process from pre-installation through to product readiness: |
Step | Phase | Owner | Action | Tools / Systems |
|---|---|---|---|---|
1 | Pre-Installation | Matilda | Publish all pre-requisite and installation documentation | Document360 |
2 | Customer Onboarding | CSM | Review of customer request and requirements | Salesforce |
3 | Deployment Decision | Salesforce (Matilda) | Decide deployment model (Hosted) | Automation |
4 | Customer Notification | Salesforce (Matilda) | Send Quick Start and pre-requisite links to customer | Email + Document360 |
5 | Environment Setup | Customer | Provision VM / Proxy VM as per pre-requisites | Customer Infra |
6 | VM Validation | Customer | Validate VM readiness | Matilda Utilities |
7 | Service Account Setup | Customer | Create service accounts and configure permissions | Scripts / Internal Process |
8 | Service Account Validation | Customer | Validate access and permissions | Matilda Utilities |
9 | Ready for Install | Customer → CSM | Share VM details (IP, OS, assets) with CSM | Email / Salesforce |
10 | Script Generation | CSM | Register VM and generate installation script | MDeploy |
11 | Software Installation | Customer | Execute installation script | MDeploy Script |
12 | License Activation | Matilda | Validate license | Matilda Scripts |
13 | Installation Complete | Customer | Product ready for Discovery | Matilda Platform |
Q: Rehost engagements often fail to complete within a predictable timeframe due to excessive system load and fragmented execution. What is the recommended approach? Streamlining the migration approach by following cloud provider best practices is essential. The key principles are: |
- Start with a thorough Discovery & Assessment and build a migration wave plan rather than attempting a full lift-and-shift in one pass.
- Prepare the source environment — a clean source results in fewer post-migration issues and ensures Matilda Rehost pre-requisites are in place.
- Ensure OS and driver readiness before initiating replication.
- Design cloud-native networking from the outset.
- Apply security by design throughout the migration lifecycle.
- Choose the right storage strategy for the target cloud environment.
- Enable block-level replication and conduct a test instance launch before cutover.
- Conduct Proof of Concept (PoC) before proceeding with full-scale rehost migration.
- Plan cutover carefully to minimise downtime.
- Perform thorough post-migration validation before decommissioning source systems.
- Enable monitoring and observability from day one on the target environment.
- Establish backup and disaster recovery policies immediately post-migration.
- Maintain governance and compliance documentation throughout.
Q: Lack of proactive notifications during Matilda engagements limits visibility for SMEs and CSMs, leading to delayed responses during critical phases. How can this be resolved? Proactive email notifications should be implemented for hosted engagements at key milestones. This enables SMEs and CSMs to monitor discovery and assessment progress in real time, identify and resolve issues early, and maintain feedback loops between customer discoveries and product teams. Automated notifications should cover: |
- Newly discovered servers added to the migration scope
- Replication status updates (started, in progress, completed, failed)
- Cutover completion confirmations
Matilda Cloud · Self-Service Migration Platform · Product Overview & Operational Guide