On-Premise to Cloud Migration Guide

The Case for Cloud Migration

Indian enterprises are accelerating their cloud adoption. Whether driven by cost optimization, scalability needs, or the push for digital transformation post-pandemic, migrating on-premise applications to cloud infrastructure is no longer optional—it's strategic.

But migration isn't just "lift and shift." Poorly planned migrations lead to unexpected costs, performance degradation, and extended downtime. This guide walks you through a structured approach that works for Indian businesses of all sizes.

Phase 1: Assessment and Discovery

Before moving a single byte, understand what you have.

Application Inventory

Create a comprehensive inventory of your current infrastructure:

+-----------------------------------------------------------------------+
|              APPLICATION INVENTORY TEMPLATE                           |
+----------------+--------+--------+---------+------------------------+
| Application    | Servers|  OS    | Database| Dependencies            |
+----------------+--------+--------+---------+------------------------+
| ERP System     | 3      | CentOS | Oracle  | LDAP, SMTP, NFS        |
|                |        |  7     | 19c    |                         |
+----------------+--------+--------+---------+------------------------+
| CRM Portal     | 2      | Ubuntu | MySQL   | Redis, External API     |
|                |        | 20.04  | 8.0    |                         |
+----------------+--------+--------+---------+------------------------+
| HR System      | 1      | Windows| SQL     | Active Dir, File shares |
|                |        | Server | Server  |                         |
+----------------+--------+--------+---------+------------------------+

Dependency Mapping

Map how applications communicate. Use network flow data to identify:

**Internal dependencies**: Which apps talk to each other?
**External dependencies**: Third-party APIs, payment gateways, government portals (GST, EPFO)
**Shared resources**: Centralized databases, file servers, authentication systems

The 6 R's of Migration

For each application, decide its migration strategy:

1. **Rehost (Lift and Shift)**: Move as-is to cloud VMs. Fastest but doesn't leverage cloud-native features. 2. **Replatform**: Minor optimizations during migration. Move Oracle to managed PostgreSQL, for example. 3. **Refactor/Rearchitect**: Redesign for cloud-native. Most effort, highest long-term value. 4. **Repurchase**: Replace with SaaS. Move from on-premise email to Google Workspace. 5. **Retire**: Decommission applications no longer needed. 6. **Retain**: Keep on-premise for now. Some applications have regulatory requirements or legacy dependencies.

Phase 2: Infrastructure Planning

Choosing the Right Cloud Architecture

For Indian deployments, consider data residency requirements. RBI, SEBI, and IRDAI have specific guidelines about where financial and insurance data must be stored.

+-----------------------------------------------------------+
|                  TARGET ARCHITECTURE                       |
|                                                           |
|  +----------+    +----------+    +-----------------+      |
|  | Mumbai   |    | Chennai  |    | Disaster Recovery|     |
|  | Primary  |<-->| Secondary|<-->|    (Pune)        |     |
|  | Region   |    | Region   |    |                  |     |
|  +----+-----+    +----+-----+    +--------+---------+     |
|       |               |                   |               |
|  +----v-----+    +----v-----+    +--------v---------+     |
|  |App Tier  |    |App Tier  |    |   App Tier (Standby)|  |
|  |DB Tier   |    |DB Replica|    |   DB Replica        |  |
|  |Cache Tier|    |Cache Tier|    |   Cache Tier        |  |
|  +----------+    +----------+    +--------------------+   |
+-----------------------------------------------------------+

Compute Sizing

Right-sizing prevents overspending. A common mistake is migrating to cloud instances matching your physical server specs.

**Reality check**: On-premise servers typically run at 15-25% utilization. Your 64GB RAM physical server probably needs a 16GB cloud instance.

Monitor your current workloads for 2-4 weeks: - Peak CPU usage - Peak memory usage - Disk IOPS requirements - Network bandwidth patterns

Database Migration Strategy

Databases are the trickiest part of any migration.

**MySQL/MariaDB**: Relatively straightforward. Use `mysqldump` for smaller databases (<100GB) or MySQL replication for larger ones.

# Set up replication from on-premise to cloud
# On source (on-premise) server:
mysqldump --single-transaction --routines --triggers --master-data=2 \
    --all-databases > migration_dump.sql

# On cloud destination: mysql < migration_dump.sql CHANGE MASTER TO MASTER_HOST='on-prem-server-ip', MASTER_USER='repl_user', MASTER_PASSWORD='secure_password', MASTER_LOG_FILE='mysql-bin.000042', MASTER_LOG_POS=12345; START SLAVE; ```

**Oracle/SQL Server**: Consider migrating to PostgreSQL to reduce licensing costs. Tools like Ora2Pg help convert Oracle schemas.

**Legacy databases**: If you're running Informix, DB2, or other legacy systems, wrap them in an API layer during migration rather than attempting a direct database migration.

Phase 3: Network Design

Connectivity Options

**Site-to-Site VPN**: Encrypted tunnel between your office datacenter and cloud. Quick to set up, suitable for moderate bandwidth needs.

# StrongSwan IPsec VPN configuration (cloud side)
conn onprem-to-cloud
    authby=secret
    left=%defaultroute
    leftid=CLOUD_PUBLIC_IP
    leftsubnet=10.1.0.0/16
    right=ONPREM_PUBLIC_IP
    rightsubnet=192.168.0.0/16
    ike=aes256-sha256-modp2048
    esp=aes256-sha256
    keyexchange=ikev2
    auto=start

**Dedicated Connection**: For large data transfers and low-latency requirements, a dedicated circuit (like a leased line) provides consistent performance. Essential for Indian enterprises with heavy database replication needs.

IP Address Planning

Don't reuse your on-premise IP ranges. Design a new addressing scheme:

Cloud VPC:           10.0.0.0/16
+-- Application:     10.0.1.0/24
+-- Database:        10.0.2.0/24
+-- Management:      10.0.3.0/24
+-- DMZ:             10.0.4.0/24
+-- Shared Services: 10.0.5.0/24

Phase 4: Migration Execution

The Migration Window

For Indian businesses, plan migration windows around business cycles:

**Avoid**: Month-end (financial closing), quarter-end, festival seasons, salary processing dates
**Prefer**: Weekend nights (Saturday 11 PM to Sunday 6 AM IST)
**Always**: Have a rollback plan tested before the migration window

Step-by-Step Migration Runbook

T-7 days:  Final staging environment testing
T-3 days:  Notify all stakeholders, prepare rollback procedures
T-1 day:   Sync data, verify replication lag
T-4 hours: Final sync, stop writes to source
T-2 hours: Verify data consistency
T-1 hour:  Update DNS TTL to 60 seconds
T-0:       Execute DNS cutover
T+15 min:  Verify application functionality
T+1 hour:  Monitor error rates and performance
T+24 hours: Confirm stability, increase DNS TTL
T+7 days:  Decommission source (after backup)

Data Transfer Methods

**Small datasets (<1TB)**: Transfer over VPN or public internet with encryption.

**Large datasets (1TB-50TB)**: Use physical data transfer devices or dedicated connections.

**Continuous sync**: Set up database replication for zero-downtime migration.

Phase 5: Post-Migration Optimization

Right-Sizing

After 2 weeks of production traffic on cloud:

# Example monitoring analysis
Instance: m5.2xlarge (8 vCPU, 32GB RAM)
Average CPU: 22%
Average Memory: 45%
Recommendation: m5.xlarge (4 vCPU, 16GB RAM)
Estimated savings: 50% on compute costs

Security Hardening

Update firewall rules for cloud networking model
Implement cloud-native security groups and NACLs
Enable encryption at rest for all storage
Set up cloud audit logging
Review and rotate all credentials

Cost Management

Set up billing alerts and tagging:

Environment Tags:
+-- env: production / staging / development
+-- team: engineering / marketing / finance
+-- project: erp-migration / crm-migration
+-- cost-center: CC-1001 / CC-1002

Real-World Example: Manufacturing Company Migration

A Coimbatore-based textile manufacturer migrated their ERP and supply chain systems:

**Scope**: 12 physical servers, Oracle database, 2TB of data **Duration**: 8 weeks total (4 weeks planning, 4 weeks execution) **Strategy**: Replatform ERP to cloud VMs, migrate Oracle to PostgreSQL **Downtime**: 4 hours total (Saturday 11 PM to 3 AM) **Result**: 40% reduction in IT infrastructure costs, 3x improvement in disaster recovery capability, and the ability to scale compute during order processing peaks

Common Pitfalls

**Underestimating data transfer time**: 2TB over a 100Mbps connection takes 44+ hours. Plan accordingly.

**Ignoring application licensing**: Some software licenses are tied to hardware or physical servers. Verify cloud licensing before migration.

**Skipping load testing**: Test your application under peak load on cloud infrastructure before going live.

**No rollback plan**: Always have a tested rollback procedure. DNS-based cutover makes rollback relatively straightforward.

Migration is a journey, not a weekend project. Take the time to plan thoroughly, test extensively, and execute methodically. The cloud rewards patience with flexibility, scalability, and cost efficiency.

Key Takeaways

**Assessment before action** — inventory all applications, map dependencies, and classify each workload using the 6 R's (rehost, replatform, refactor, retain, retire, repurchase) before choosing a migration strategy.
**Data transfer time is often underestimated** — 2 TB over a 100 Mbps connection takes 44+ hours; plan for physical data transfer or staged sync for large datasets.
**Test under peak load on cloud infrastructure** before cutover — performance characteristics differ from on-premise hardware, and licensing restrictions may change in virtualized environments.
**Use DNS-based cutover** for the migration window so you can roll back to on-premise quickly if the cloud deployment fails validation.
**Right-size and optimize after migration** — monitor actual resource usage for 2–4 weeks and adjust instance sizes, reserved capacity, and security rules based on real data, not estimates.

Migrating On-Premise Applications to Cloud: A Step-by-Step Guide for Indian Enterprises