Module 17: Migration Strategies and System Upgrades

Master strategies for migrating SLT environments and upgrading systems with minimal downtime.

1. Migration Scenarios

graph LR
    A[Current State] --> B{Migration Type}
    B -->|Version Upgrade| C[SLT/HANA Upgrade]
    B -->|Platform Migration| D[On-Prem → Cloud]
    B -->|Consolidation| E[Multiple → Single]
    B -->|Expansion| F[Single → Distributed]

Common Migration Types

Migration Type	Downtime	Complexity	Risk	Duration
SLT Version Upgrade	2-4 hours	Medium	Low	1 day
HANA Upgrade	4-8 hours	High	Medium	2-3 days
On-Prem to Cloud	8-24 hours	Very High	High	2-4 weeks
Landscape Consolidation	4-12 hours	High	Medium	1-2 weeks

2. SLT Version Upgrade

Pre-Upgrade Assessment

# Check current version
Transaction: SYSTEM → Status → Component Information
Current: SLT 2.0 SP12
Target: SLT 2.0 SP15

# Compatibility check
sapup check prerequisites
sapup check <SID>

# Result:
✓ OS version compatible
✓ Kernel version compatible
✓ Database version compatible
⚠ Custom code needs review
✗ Note 3234567 must be implemented

Upgrade Procedure

Step 1: Prepare for Upgrade (1-2 days before)

1.1 Review SAP Notes:
    - Check all notes for SP15
    - Implement mandatory prerequisites
    
1.2 Backup current system:
    Full backup of HANA and SLT

1.3 Export configurations:
    Transaction: LTRC → Export all MT_IDs

1.4 Document current state:
    - Active MT_IDs list
    - Replication statistics
    - Custom developments

1.5 Schedule downtime window:
    Recommended: Saturday 00:00-08:00

Step 2: Upgrade Execution

2.1 Stop replication (23:45):
    Transaction: LTRC → Stop All MT_IDs
    Verify: SELECT COUNT(*) FROM /DMIS/DT_STATUS WHERE STATUS='RUNNING'
    Result: 0

2.2 Stop SLT system (23:55):
    stopsap r3

2.3 Backup system (00:00):
    BACKUP DATA USING FILE ('PRE_UPGRADE_BACKUP')

2.4 Run SUM (Software Update Manager) (00:30):
    cd /usr/sap/SUM/
    ./STARTUP

    SUM Steps:
    ├── Extraction Phase (30 min)
    ├── Configuration Phase (15 min)
    ├── Import Phase (90 min)
    ├── Execution Phase (60 min)
    └── Cleanup Phase (15 min)
    
    Total: ~3.5 hours

2.5 Post-upgrade tasks (04:00):
    - Start SAP system: startsap
    - Run transaction SICK (consistency check)
    - Implement post-upgrade notes
    - Test basic functionality

2.6 Restart replication (06:00):
    Transaction: LTRC → Start All MT_IDs
    Monitor for 1 hour

2.7 Validation (07:00):
    - Check data flow
    - Verify transformations
    - Compare record counts
    - Performance benchmarking

2.8 Go-live (08:00):
    - Open system to users
    - Communicate completion
    - Monitor closely for 24 hours

Post-Upgrade Validation

-- Compare record counts pre/post upgrade
SELECT 
  MT_ID,
  TABLE_NAME,
  COUNT(*) as RECORD_COUNT
FROM /DMIS/DT_STATUS
GROUP BY MT_ID, TABLE_NAME
ORDER BY MT_ID, TABLE_NAME;

-- Monitor performance
SELECT 
  MT_ID,
  AVG(DURATION_MS) as AVG_DURATION,
  MAX(DURATION_MS) as MAX_DURATION
FROM /DMIS/PERFORMANCE_LOG
WHERE TIMESTAMP >= ADD_HOURS(CURRENT_TIMESTAMP, -1)
GROUP BY MT_ID;

-- Check for errors
SELECT * FROM /DMIS/LOG_ERROR
WHERE TIMESTAMP >= ADD_HOURS(CURRENT_TIMESTAMP, -24)
ORDER BY TIMESTAMP DESC;

3. HANA Database Upgrade

Planning

Current: HANA 2.0 SPS04
Target: HANA 2.0 SPS07

Pre-requisites:
├── Review HANA Master Guide
├── Check hardware requirements
├── Verify OS compatibility
├── Review SAP Notes (specifically for SPS07)
└── Plan downtime (recommend 8-12 hours)

HANA Upgrade with SLT

#!/bin/bash
# hana_upgrade_with_slt.sh

LOG="/var/log/hana_upgrade_$(date +%Y%m%d).log"

log() {
  echo "$(date): $1" | tee -a "$LOG"
}

log "=== HANA Upgrade Started ==="

# 1. Stop SLT replication
log "Step 1: Stopping SLT replication"
su - sltadm -c "sapcontrol -nr 00 -function Stop"

# 2. Backup HANA
log "Step 2: Creating HANA backup"
su - hdbadm -c "hdbsql -u SYSTEM -p SysPass \
  \"BACKUP DATA USING FILE ('PRE_UPGRADE_HANA_BACKUP')\""

# 3. Stop HANA
log "Step 3: Stopping HANA"
su - hdbadm -c "HDB stop"

# 4. Extract new HANA media
log "Step 4: Extracting HANA SPS07 media"
cd /hana/shared/media
SAPCAR -xvf IMDB_SERVER20_057.SAR

# 5. Run hdblcm (HANA Lifecycle Manager)
log "Step 5: Running hdblcm"
cd /hana/shared/media/SAP_HANA_DATABASE
./hdblcm --action=update \
  --autostart=no \
  --userid=hdbadm \
  --batch

# Wait for completion (2-4 hours)

# 6. Start HANA
log "Step 6: Starting HANA"
su - hdbadm -c "HDB start"

# 7. Verify HANA version
log "Step 7: Verifying HANA version"
NEW_VERSION=$(su - hdbadm -c "HDB version" | grep version | awk '{print $2}')
log "New HANA version: $NEW_VERSION"

# 8. Start SLT
log "Step 8: Starting SLT"
su - sltadm -c "startsap"

# 9. Restart replication
log "Step 9: Restarting replication"
# Use RFC to start MT_IDs

log "=== HANA Upgrade Completed ==="

4. On-Premise to Cloud Migration

Migration Strategy

Phase 1: Assessment (Week 1-2)
├── Inventory current systems
├── Estimate data volume
├── Network bandwidth analysis
├── Cost analysis
└── Risk assessment

Phase 2: Preparation (Week 3-4)
├── Provision cloud infrastructure
├── Set up cloud connector
├── Configure network (VPN/ExpressRoute)
├── Create cloud HANA instance
└── Test connectivity

Phase 3: Initial Load (Week 5)
├── Perform initial data load
├── Validate data integrity
├── Set up delta replication
└── Performance tuning

Phase 4: Cutover (Week 6)
├── Final delta sync
├── Switch applications to cloud
├── Decommission on-premise
└── Post-migration support

Implementation

Day 1-2: Infrastructure Setup

Cloud Provider: Azure
Region: East US
Resources:
├── VM: Standard_M128s (128 vCPU, 2 TB RAM)
├── Storage: Premium SSD (10 TB)
├── Network: ExpressRoute (10 Gbps)
└── Backup: GRS storage account

Install HANA on Azure VM:
1. Deploy VM from marketplace
2. Install HANA 2.0 SPS07
3. Configure storage layout
4. Enable Azure Backup

Day 3-4: Network Configuration

Set up Cloud Connector:
1. Install on-premise gateway
2. Configure subaccount connection
3. Map internal HANA to virtual host
4. Test connectivity

Verify network:
ping azure-hana.cloudapp.com
iperf3 -c azure-hana.cloudapp.com
→ Bandwidth: 8 Gbps
→ Latency: 15ms

Day 5-7: Initial Load

Method: HANA System Replication

On-Premise HANA:
hdbnsutil -sr_enable --name=ONPREM

Cloud HANA:
hdbnsutil -sr_register \
  --name=CLOUD \
  --remoteHost=onprem-hana \
  --remoteInstance=00 \
  --replicationMode=async \
  --operationMode=logreplay

Wait for full sync:
hdbnsutil -sr_state
→ Status: ACTIVE, fully synchronized

Day 8-9: SLT Configuration

Option 1: Migrate SLT to cloud
- Install SLT on cloud VM
- Import MT_ID configurations
- Point to cloud HANA

Option 2: Keep SLT on-premise
- Update MT_ID target to cloud HANA
- Use cloud connector for connectivity

Day 10: Cutover

1. Stop applications (Downtime starts)
2. Stop SLT replication
3. Final HANA sync
4. Takeover cloud HANA:
   hdbnsutil -sr_takeover
5. Update application connections
6. Start SLT replication
7. Validate data flow
8. Open applications (Downtime ends)

Downtime: 2-4 hours

5. Zero-Downtime Migration

Live Migration Strategy

Technique: Dual-Write Pattern

Architecture:
ERP → SLT_OLD → HANA_OLD → Apps (Current)
ERP → SLT_NEW → HANA_NEW → Apps (Parallel)

Step 1: Set up parallel replication
Create MT_ID on new system
Replicate same tables as old system
Run in parallel for 1 week

Step 2: Data validation
Compare record counts daily
Check for discrepancies
Resolve any issues

Step 3: Gradual cutover
Week 1: 10% traffic to new system
Week 2: 25% traffic
Week 3: 50% traffic
Week 4: 100% traffic

Step 4: Decommission old system
Stop old SLT
Remove old HANA
Success!

Total downtime: 0 minutes

Implementation Example

-- Data validation script
CREATE PROCEDURE VALIDATE_MIGRATION()
AS
BEGIN
  DECLARE v_table NVARCHAR(30);
  DECLARE v_count_old INT;
  DECLARE v_count_new INT;
  DECLARE v_diff INT;
  
  FOR v AS (
    SELECT DISTINCT TABLE_NAME 
    FROM /DMIS/REPLICATION_TABLES
  ) DO
    v_table = v.TABLE_NAME;
    
    -- Count records in old system
    SELECT COUNT(*) INTO v_count_old
    FROM "OLD_SCHEMA"."v_table";
    
    -- Count records in new system
    SELECT COUNT(*) INTO v_count_new
    FROM "NEW_SCHEMA"."v_table";
    
    v_diff = ABS(v_count_old - v_count_new);
    
    INSERT INTO MIGRATION_VALIDATION VALUES (
      v_table,
      v_count_old,
      v_count_new,
      v_diff,
      CASE WHEN v_diff = 0 THEN 'MATCH' ELSE 'MISMATCH' END,
      CURRENT_TIMESTAMP
    );
  END FOR;
END;

-- Run daily during migration

6. Landscape Consolidation

Consolidation Scenario

Before: Multiple SLT Systems
├── SLT_DEV (Development)
├── SLT_QAS (Quality)
├── SLT_PRD (Production)
└── Total: 3 systems, 3 licenses, 3× maintenance

After: Single Multi-Tenant SLT
├── SLT_SHARED
│   ├── Tenant: DEV
│   ├── Tenant: QAS
│   └── Tenant: PRD
└── Total: 1 system, 1 license, 1× maintenance

Savings: 66% cost reduction

Implementation

Step 1: Provision larger system
Hardware: 32 vCPU, 256 GB RAM (vs. 3× 8 vCPU, 64 GB)
Cost: $5K/month vs. $6K/month (3× $2K)

Step 2: Create tenant databases
CREATE DATABASE DEV_TENANT SYSTEM USER PASSWORD SysPass;
CREATE DATABASE QAS_TENANT SYSTEM USER PASSWORD SysPass;
CREATE DATABASE PRD_TENANT SYSTEM USER PASSWORD SysPass;

Step 3: Migrate configurations
Export from old systems:
LTRC → Export → MT_ID_DEV_*
LTRC → Export → MT_ID_QAS_*
LTRC → Export → MT_ID_PRD_*

Import to new system:
LTRC → Import → Select tenant → Import XML

Step 4: Data migration
Use HANA system replication or backup/restore
for each tenant

Step 5: Cutover
Stop old SLT systems one by one
Start corresponding tenant on new system
Validate and move to next

Step 6: Decommission
Remove old systems after 30 days validation

7. Rollback Procedures

Upgrade Rollback

#!/bin/bash
# rollback_slt_upgrade.sh

log() {
  echo "$(date): $1" | tee -a /var/log/rollback.log
}

log "=== ROLLBACK INITIATED ==="

# 1. Stop current system
log "Stopping upgraded system"
stopsap r3

# 2. Restore from backup
log "Restoring from pre-upgrade backup"
hdbsql -u SYSTEM -p SysPass \
  "RECOVER DATA USING FILE ('PRE_UPGRADE_BACKUP') CLEAR LOG"

# 3. Start old system
log "Starting restored system"
startsap

# 4. Verify version
log "Verifying system version"
# Should show old version

# 5. Resume replication
log "Resuming replication"
# MT_IDs should auto-start

log "=== ROLLBACK COMPLETED ==="
log "Estimated data loss: Based on replication downtime"

8. Testing and Validation

Migration Test Checklist

• Backup successfully restored
• All MT_IDs visible
• Replication starts without errors
• Record counts match source
• Transformations working correctly
• Performance meets baseline
• Monitoring dashboards functional
• Alerts configured
• User access validated
• Documentation updated

Performance Comparison

-- Benchmark before and after
SELECT 
  'BEFORE' as PHASE,
  AVG(THROUGHPUT_REC_SEC) as AVG_THROUGHPUT,
  AVG(LATENCY_MS) as AVG_LATENCY
FROM MIGRATION_BENCHMARK_BEFORE
UNION ALL
SELECT 
  'AFTER',
  AVG(THROUGHPUT_REC_SEC),
  AVG(LATENCY_MS)
FROM MIGRATION_BENCHMARK_AFTER;

-- Expected result:
PHASE   AVG_THROUGHPUT  AVG_LATENCY
BEFORE  2,500           1,200ms
AFTER   2,450           1,250ms
        (±2% acceptable)

9. Best Practices

Migration Planning

1. Always have rollback plan
2. Test in non-production first
3. Schedule adequate downtime window
4. Communicate early and often
5. Have support resources available
6. Document every step
7. Validate thoroughly before cutover
8. Monitor closely for 48 hours post-migration
9. Keep old system available for 30 days
10. Conduct post-migration review

Risk Mitigation

High-Risk Areas:
├── Data loss during cutover
│   → Solution: System replication, dual-write
├── Extended downtime
│   → Solution: Rehearse migration, have rollback
├── Performance degradation
│   → Solution: Benchmark and tune
├── Incompatible customizations
│   → Solution: Review and test all custom code
└── Network issues
    → Solution: Redundant connectivity, bandwidth testing

10. Migration Checklist

Pre-Migration (2-4 weeks before)

• Project plan approved
• Backup strategy defined
• Rollback procedure documented
• Test environment migration completed
• Performance baseline captured
• Stakeholders informed
• Downtime window scheduled
• Support team briefed

Migration Day

• Go/No-go decision made
• All backups completed
• Communication sent to users
• Migration steps executed
• Validation tests passed
• Performance verified
• Users notified of completion
• Monitoring enabled

Post-Migration (1-4 weeks after)

• Daily monitoring for 1 week
• Performance trending analysis
• Issue log reviewed
• Documentation updated
• Lessons learned captured
• Old system decommissioned (after 30 days)
• Project closure report
• Celebration! 🎉

Summary

✅ Migration scenario analysis ✅ SLT version upgrade procedures ✅ HANA database upgrade with SLT ✅ On-premise to cloud migration ✅ Zero-downtime migration strategies ✅ Landscape consolidation ✅ Rollback procedures ✅ Testing and validation ✅ Best practices ✅ Comprehensive checklists

Next: Module 18 - Troubleshooting Guide