Migration Planning - Learning Module

Loading content...

0/273

Measuring Success

What Gets Measured Gets Done

"How do we know if this migration is actually working?" This question haunts every large-scale migration. Organizations invest millions of dollars and years of engineering effort on the promise of improved velocity, scalability, and reliability. Yet many complete migrations without clear evidence of benefit. Others abandon migrations prematurely, unable to demonstrate progress.

Measurement is the antidote to migration ambiguity. Clear metrics provide objective progress indicators, justify continued investment, identify areas needing attention, and ultimately prove whether the transformation delivered its promised value. Without measurement, migration becomes an act of faith—expensive faith that leadership eventually loses.

What You'll Learn

This page covers comprehensive success measurement for microservices migration: defining meaningful metrics across business, technical, and organizational dimensions; building measurement infrastructure; establishing baselines; tracking and visualizing progress; communicating results to stakeholders; and calculating return on investment.

Why Measurement Matters

Measurement serves multiple critical purposes throughout a migration journey. Without it, teams operate on intuition, executives lose confidence, and the organization can't learn or adapt effectively.

What Measurement Enables:

Purposes of Migration Measurement

•Progress Verification: Are we actually moving forward? Metrics distinguish real progress from activity theater.
•Investment Justification: Why should we continue funding this? Quantified benefits justify continued expenditure.
•Problem Detection: Where are we struggling? Declining metrics signal areas needing intervention before they become crises.
•Decision Support: Should we accelerate, pause, or change course? Data informs strategic decisions.
•Organizational Learning: What approaches work best? Metrics reveal which patterns to replicate and which to avoid.
•Stakeholder Communication: How do we demonstrate value? Concrete numbers communicate more effectively than narratives.
•Team Motivation: Is our work making a difference? Teams perform better when they see the impact of their efforts.

The Measurement Tax

Measurement isn't free. Implementing metrics requires engineering effort, maintaining dashboards requires ongoing attention, and chasing vanity metrics can distort behavior. Be deliberate about what you measure. The right few metrics provide clarity; measuring everything creates noise. Start with essential metrics and add selectively.

Categories of Success Metrics

Success metrics fall into three major categories: business value metrics (what executives care about), technical health metrics (what engineers care about), and organizational metrics (what both should care about). A comprehensive measurement strategy addresses all three.

The Three Pillars of Migration Metrics:

Migration Metrics Taxonomy
Category	Focus	Primary Audience	Example Metrics
Business Value	Impact on business outcomes	Executives, Product, Finance	Feature lead time, time-to-market, infrastructure costs, revenue impact
Technical Health	System quality and performance	Engineering, Ops, Architecture	Deployment frequency, change failure rate, MTTR, system reliability
Organizational	Team effectiveness and satisfaction	HR, Management, Teams	Developer productivity, team autonomy, knowledge distribution, satisfaction

Lagging vs Leading Indicators:

Metrics can be lagging (measure outcomes after the fact) or leading (predict future outcomes). Both are valuable:

Lagging Indicators

•Deployment frequency (measures past deployments)
•Incident count (measures past failures)
•Feature delivery time (measures past projects)
•Infrastructure costs (measures past spend)
•Customer satisfaction (measures past experience)

Leading Indicators

•Test coverage (predicts change safety)
•Code coupling metrics (predicts extraction difficulty)
•On-call burden (predicts burnout, attrition)
•Technical debt accumulation (predicts future velocity)
•Team training completion (predicts capability)

Balance Leading and Lagging

Lagging indicators confirm whether you achieved goals; leading indicators warn whether you're on track to achieve them. A dashboard showing only lagging indicators provides hindsight without foresight. Include leading indicators to enable proactive intervention.

DORA Metrics: The Industry Standard

The DevOps Research and Assessment (DORA) team identified four key metrics that predict software delivery performance. These metrics are extensively validated across thousands of organizations and correlate strongly with organizational success. They should be central to any migration measurement strategy.

The Four DORA Metrics:

DORA Metrics Definitions and Targets
Metric	Definition	Elite	High	Medium	Low
Deployment Frequency	How often code is deployed to production	On-demand (multiple per day)	Daily to weekly	Weekly to monthly	Monthly+
Lead Time for Changes	Time from code commit to production deployment	< 1 hour	1 day - 1 week	1 week - 1 month	1 month
Change Failure Rate	% of deployments causing failures requiring remediation	0-15%	16-30%	16-30%	46-60%
Mean Time to Recovery	Time to restore service after incident	< 1 hour	< 1 day	1 day - 1 week	1 week

DORAMetrics.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
// DORA Metrics Collection and Tracking
 
interface DORAMetrics {
  period: {
    start: Date;
    end: Date;
  };
  
  deploymentFrequency: {
    totalDeployments: number;
    deploymentsPerDay: number;
    serviceBreakdown: Map<string, number>;
    trend: 'improving' | 'stable' | 'declining';
  };
  
  leadTimeForChanges: {
    medianMinutes: number;
    p90Minutes: number;
    breakdown: {
      codingTime: number;
      reviewTime: number;
      testingTime: number;
      deploymentTime: number;
    };
    trend: 'improving' | 'stable' | 'declining';
  };
  
  changeFailureRate: {
    totalDeployments: number;
    failedDeployments: number;
    rate: number;
    trend: 'improving' | 'stable' | 'declining';
  };
  
  meanTimeToRecovery: {
    totalIncidents: number;
    medianRecoveryMinutes: number;
    p90RecoveryMinutes: number;
    trend: 'improving' | 'stable' | 'declining';
  };
  
  overallPerformanceLevel: 'elite' | 'high' | 'medium' | 'low';
}
 
// Calculate DORA performance level
function calculateDORALevel(metrics: DORAMetrics): 'elite' | 'high' | 'medium' | 'low' {
  const scores: number[] = [];
  
  // Deployment Frequency scoring
  if (metrics.deploymentFrequency.deploymentsPerDay >= 1) scores.push(4);
  else if (metrics.deploymentFrequency.deploymentsPerDay >= 0.2) scores.push(3);
  else if (metrics.deploymentFrequency.deploymentsPerDay >= 0.1) scores.push(2);
  else scores.push(1);
  
  // Lead Time scoring
  const leadTimeHours = metrics.leadTimeForChanges.medianMinutes / 60;
  if (leadTimeHours <= 1) scores.push(4);
  else if (leadTimeHours <= 24 * 7) scores.push(3);
  else if (leadTimeHours <= 24 * 30) scores.push(2);
  else scores.push(1);
  
  // Change Failure Rate scoring
  const cfr = metrics.changeFailureRate.rate * 100;
  if (cfr <= 15) scores.push(4);
  else if (cfr <= 30) scores.push(3);
  else if (cfr <= 45) scores.push(2);
  else scores.push(1);
  
  // MTTR scoring
  const mttrHours = metrics.meanTimeToRecovery.medianRecoveryMinutes / 60;
  if (mttrHours <= 1) scores.push(4);
  else if (mttrHours <= 24) scores.push(3);
  else if (mttrHours <= 24 * 7) scores.push(2);
  else scores.push(1);
  
  const avgScore = scores.reduce((a, b) => a + b, 0) / scores.length;
  
  if (avgScore >= 3.5) return 'elite';
  if (avgScore >= 2.5) return 'high';
  if (avgScore >= 1.5) return 'medium';
  return 'low';
}
 
// Track DORA metrics over migration timeline
interface DORAProgress {
  baseline: DORAMetrics;       // Before migration
  current: DORAMetrics;        // Current state
  target: DORAMetrics;         // Migration goal
  historicalTrend: DORAMetrics[];  // Monthly snapshots
}
 
// Example: Migration DORA Progress
const migrationDORAProgress: DORAProgress = {
  baseline: {
    period: { start: new Date('2023-01-01'), end: new Date('2023-03-31') },
    deploymentFrequency: {
      totalDeployments: 12,
      deploymentsPerDay: 0.13,  // ~Monthly
      serviceBreakdown: new Map([['monolith', 12]]),
      trend: 'stable',
    },
    leadTimeForChanges: {
      medianMinutes: 20160,  // 14 days
      p90Minutes: 43200,     // 30 days
      breakdown: { codingTime: 4320, reviewTime: 2880, testingTime: 10080, deploymentTime: 2880 },
      trend: 'stable',
    },
    changeFailureRate: {
      totalDeployments: 12,
      failedDeployments: 4,
      rate: 0.33,
      trend: 'stable',
    },
    meanTimeToRecovery: {
      totalIncidents: 24,
      medianRecoveryMinutes: 180,  // 3 hours
      p90RecoveryMinutes: 720,     // 12 hours
      trend: 'stable',
    },
    overallPerformanceLevel: 'low',
  },
  
  current: {
    period: { start: new Date('2024-10-01'), end: new Date('2024-12-31') },
    deploymentFrequency: {
      totalDeployments: 245,
      deploymentsPerDay: 2.7,  // Multiple times per day
      serviceBreakdown: new Map([
        ['monolith', 15],
        ['order-service', 45],
        ['payment-service', 38],
        ['notification-service', 67],
        ['catalog-service', 42],
        ['inventory-service', 38],
      ]),
      trend: 'improving',
    },
    leadTimeForChanges: {
      medianMinutes: 240,  // 4 hours
      p90Minutes: 720,     // 12 hours
      breakdown: { codingTime: 120, reviewTime: 60, testingTime: 30, deploymentTime: 30 },
      trend: 'improving',
    },
    changeFailureRate: {
      totalDeployments: 245,
      failedDeployments: 22,
      rate: 0.09,
      trend: 'improving',
    },
    meanTimeToRecovery: {
      totalIncidents: 18,
      medianRecoveryMinutes: 35,
      p90RecoveryMinutes: 90,
      trend: 'improving',
    },
    overallPerformanceLevel: 'elite',
  },
  
  target: {
    // ... Elite performance targets
    overallPerformanceLevel: 'elite',
  },
  
  historicalTrend: [], // Monthly snapshots
};

DORA Metrics Are Outcome-Focused

DORA metrics measure outcomes (how well are we delivering software?), not activities (how many story points did we complete?). This makes them resistant to gaming and genuinely reflective of capability improvement. A team can inflate story points; they can't fake having actually deployed to production.

Additional Technical Metrics

Beyond DORA metrics, additional technical measures capture migration-specific progress and system health.

Migration-Specific Technical Metrics:

Technical Metrics for Migration
Metric	What It Measures	Why It Matters	Target Direction
Monolith Traffic %	% of requests handled by monolith	Primary extraction progress indicator	Decreasing → 0%
Service Count	Number of services in production	Decomposition progress	Increasing → target count
Service Independence	% of services that deploy without monolith changes	True decoupling measurement	Increasing → 100%
Cross-Service P99 Latency	End-to-end latency across service calls	Distributed system overhead	Stable or improving
Service Availability	Uptime per service (SLO achievement)	Individual service health	SLO target
Inter-Service Error Rate	Errors in service-to-service communication	Integration health	Decreasing
Database Dependencies	Services sharing database connections	Data coupling indicator	Decreasing → 0
Test Coverage (services)	Automated test coverage per service	Change safety indicator	Increasing

TechnicalMetrics.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
// Migration-Specific Technical Metrics Dashboard
 
interface MigrationTechnicalMetrics {
  extractionProgress: {
    totalServicesToExtract: number;
    servicesInProduction: number;
    servicesInDevelopment: number;
    progressPercent: number;
    
    monolithTrafficPercent: number;
    microservicesTrafficPercent: number;
    trafficTrend: TrendData;
  };
  
  serviceHealth: {
    services: ServiceHealthStatus[];
    aggregateAvailability: number;
    aggregateLatencyP99: number;
    servicesViolatingSLO: string[];
  };
  
  couplingMetrics: {
    servicesWithDbDependencies: number;
    sharedDatabaseConnections: number;
    synchronousDepChainLength: number;  // Longest sync call chain
    circularDependencies: number;
  };
  
  qualityMetrics: {
    averageTestCoverage: number;
    servicesWithContractTests: number;
    servicesWithE2ETests: number;
    technicalDebtScore: number;
  };
}
 
interface ServiceHealthStatus {
  serviceName: string;
  availability: number;  // Last 30 days
  latencyP99: number;    // ms
  errorRate: number;     // %
  deploymentCount: number;  // Last 30 days
  incidentCount: number;    // Last 30 days
  sloStatus: 'meeting' | 'at-risk' | 'violating';
}
 
// Generate migration progress visualization data
function generateMigrationProgressData(metrics: MigrationTechnicalMetrics): ProgressVisualization {
  return {
    gauge: {
      label: 'Migration Progress',
      value: metrics.extractionProgress.progressPercent,
      segments: [
        { from: 0, to: 25, color: 'red', label: 'Early' },
        { from: 25, to: 50, color: 'orange', label: 'In Progress' },
        { from: 50, to: 75, color: 'yellow', label: 'Advanced' },
        { from: 75, to: 100, color: 'green', label: 'Near Complete' },
      ],
    },
    
    trafficSplit: {
      monolith: {
        percent: metrics.extractionProgress.monolithTrafficPercent,
        trend: metrics.extractionProgress.trafficTrend,
      },
      microservices: {
        percent: metrics.extractionProgress.microservicesTrafficPercent,
        trend: metrics.extractionProgress.trafficTrend,
      },
    },
    
    serviceGrid: metrics.serviceHealth.services.map(s => ({
      name: s.serviceName,
      status: s.sloStatus,
      metrics: {
        availability: `${(s.availability * 100).toFixed(2)}%`,
        latency: `${s.latencyP99}ms`,
        deployments: s.deploymentCount,
      },
    })),
    
    alerts: [
      ...metrics.serviceHealth.servicesViolatingSLO.map(s => ({
        type: 'warning' as const,
        message: `${s} is violating SLO`,
      })),
      ...(metrics.couplingMetrics.circularDependencies > 0 ? [{
        type: 'error' as const,
        message: `${metrics.couplingMetrics.circularDependencies} circular dependencies detected`,
      }] : []),
    ],
  };
}
 
// Example current state
const currentTechnicalMetrics: MigrationTechnicalMetrics = {
  extractionProgress: {
    totalServicesToExtract: 15,
    servicesInProduction: 9,
    servicesInDevelopment: 2,
    progressPercent: 60,
    
    monolithTrafficPercent: 35,
    microservicesTrafficPercent: 65,
    trafficTrend: { direction: 'decreasing', rate: -5 },  // -5% monolith per month
  },
  
  serviceHealth: {
    services: [
      { serviceName: 'order-service', availability: 0.9995, latencyP99: 145, 
        errorRate: 0.02, deploymentCount: 18, incidentCount: 1, sloStatus: 'meeting' },
      { serviceName: 'payment-service', availability: 0.9998, latencyP99: 89, 
        errorRate: 0.01, deploymentCount: 12, incidentCount: 0, sloStatus: 'meeting' },
      { serviceName: 'notification-service', availability: 0.9989, latencyP99: 67, 
        errorRate: 0.08, deploymentCount: 24, incidentCount: 2, sloStatus: 'at-risk' },
      // ... more services
    ],
    aggregateAvailability: 0.9994,
    aggregateLatencyP99: 145,
    servicesViolatingSLO: [],
  },
  
  couplingMetrics: {
    servicesWithDbDependencies: 2,  // Order and Inventory still share some tables
    sharedDatabaseConnections: 3,
    synchronousDepChainLength: 4,   // API -> Order -> Payment -> Fraud -> Scoring
    circularDependencies: 0,
  },
  
  qualityMetrics: {
    averageTestCoverage: 78,
    servicesWithContractTests: 8,
    servicesWithE2ETests: 6,
    technicalDebtScore: 4.2,  // 1-10, lower is better
  },
};

Traffic Percentage Is the Ultimate Indicator

While service count and feature completeness matter, the most meaningful single metric is 'percent of production traffic handled by microservices.' This metric is immune to gaming—you can't fake handling real production traffic. When this reaches 100%, the migration is functionally complete.

Business and Organizational Metrics

Technical excellence means nothing if it doesn't translate to business value. And organizational health determines sustainability. These metrics connect technical progress to outcomes that matter to the broader organization.

Business Value Metrics:

Business Impact Metrics
Metric	What It Measures	How to Measure	Migration Impact
Time-to-Market	Days from idea to production	Track feature development lifecycle	Should decrease as services enable parallel development
Infrastructure Cost	Monthly cloud/hosting spend	Cloud provider bills, normalized by traffic	May increase then decrease; ultimate goal is efficiency
Developer Productivity	Features delivered per developer	Story points or features per sprint per person	Dip during learning, then improve
Revenue Impact Features	% of revenue features using microservices	Tag features by architecture	Indicates business enablement
Customer-Facing Reliability	User-perceived uptime and performance	Synthetic monitoring, RUM data	Should improve or maintain during migration
Incident Business Cost	Cost per incident (lost revenue, remediation)	Calculate per incident	Should decrease with improved MTTR

Organizational Health Metrics:

Organizational Metrics

•Developer Satisfaction (NPS/eNPS): Regular surveys measuring developer happiness with tools, processes, and workload. Drops may indicate migration burden.
•On-Call Burden: Pages per week per engineer, after-hours pages, incident duration. Poorly designed services create unsustainable on-call.
•Team Autonomy Score: Survey-based metric measuring perceived ability to make decisions, deploy independently, and own outcomes.
•Knowledge Distribution: Bus factor per service (how many people understand it). Single-person knowledge is a risk.
•Training Completion: % of team completing distributed systems training, platform training, etc.
•Attrition Rate: Departures during migration. High attrition may indicate burnout or frustration.

BusinessMetrics.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
// Business and Organizational Metrics Tracking
 
interface BusinessMetrics {
  timeToMarket: {
    averageDaysIdeaToProduction: number;
    byFeatureSize: {
      small: number;   // < 1 week dev effort
      medium: number;  // 1-4 weeks
      large: number;   // > 4 weeks
    };
    trend: TrendData;
    baselineComparison: number;  // % change from baseline
  };
  
  costs: {
    monthlyInfrastructureCost: number;
    costPerTransaction: number;
    costTrend: TrendData;
    baselineComparison: number;
  };
  
  reliability: {
    customerFacingAvailability: number;
    p95PageLoadTime: number;
    errorRateUserFacing: number;
    baselineComparison: {
      availability: number;
      performance: number;
    };
  };
}
 
interface OrganizationalMetrics {
  developerExperience: {
    npsScore: number;          // -100 to +100
    satisfactionScores: {
      tooling: number;         // 1-10
      deployment: number;
      debugging: number;
      onboarding: number;
    };
    trend: TrendData;
  };
  
  onCallHealth: {
    pagesPerWeekPerEngineer: number;
    afterHoursPagesPercent: number;
    averageIncidentDuration: number;
    escalationRate: number;
    trend: TrendData;
  };
  
  teamHealth: {
    teamAutonomyScore: number;    // 1-10 survey result
    knowledgeDistributionScore: number;  // Higher = better distributed
    trainingCompletion: number;   // %
    attritionRateLast12Months: number;
  };
}
 
// ROI Calculation
interface MigrationROI {
  investmentToDate: {
    engineeringHours: number;
    engineeringCost: number;
    infrastructureCost: number;
    toolingCost: number;
    trainingCost: number;
    consultingCost: number;
    totalInvestment: number;
  };
  
  benefitsRealized: {
    velocityImprovement: {
      hoursPerFeatureSaved: number;
      featuresDelivered: number;
      hoursSaved: number;
      costSaved: number;
    };
    infrastructureOptimization: {
      monthlySavings: number;
      cumulativeSavings: number;
    };
    incidentReduction: {
      incidentsReduced: number;
      mttrReduction: number;
      costSaved: number;
    };
    developerProductivity: {
      productivityGain: number;  // %
      equivalentFTEs: number;
    };
    totalBenefitsRealized: number;
  };
  
  projectedBenefits: {
    annualRecurringSavings: number;
    enabledRevenueOpportunities: number;
    threeYearProjectedROI: number;
  };
  
  currentROI: number;  // Benefits / Investment
  breakEvenProjection: Date;
}
 
// Example ROI calculation
const migrationROI: MigrationROI = {
  investmentToDate: {
    engineeringHours: 24000,
    engineeringCost: 2400000,  // $100/hr fully loaded
    infrastructureCost: 180000,  // Additional during parallel running
    toolingCost: 120000,
    trainingCost: 80000,
    consultingCost: 150000,
    totalInvestment: 2930000,
  },
  
  benefitsRealized: {
    velocityImprovement: {
      hoursPerFeatureSaved: 40,  // Previously 100hr avg, now 60hr
      featuresDelivered: 180,
      hoursSaved: 7200,
      costSaved: 720000,
    },
    infrastructureOptimization: {
      monthlySavings: 25000,  // Right-sizing, reduced over-provisioning
      cumulativeSavings: 300000,  // 12 months
    },
    incidentReduction: {
      incidentsReduced: 36,  // 60 to 24 annually
      mttrReduction: 0.4,    // 40% faster recovery
      costSaved: 180000,     // Incident cost reduction
    },
    developerProductivity: {
      productivityGain: 0.15,  // 15% productivity increase
      equivalentFTEs: 6,      // 40 developers * 15%
    },
    totalBenefitsRealized: 1200000,
  },
  
  projectedBenefits: {
    annualRecurringSavings: 600000,
    enabledRevenueOpportunities: 2000000,  // B2B API, faster features
    threeYearProjectedROI: 6.2,  // 620% ROI
  },
  
  currentROI: 0.41,  // 1.2M benefits / 2.93M investment = 41%
  breakEvenProjection: new Date('2025-08-01'),
};

ROI Takes Time

Don't expect positive ROI during migration. Investment is front-loaded; benefits accrue over time. Early ROI calculations will look negative—this is expected. Focus on trend (is ROI improving?) and projected ROI based on benefit acceleration curves. Break-even typically occurs 6-18 months after migration completion.

Establishing Baselines

Without baselines, you can't prove improvement. Before migration begins, invest in measuring the current state across all key metrics. This baseline becomes the reference point for all future progress claims.

Baseline Establishment Process:

Baseline Establishment Steps

•Identify Key Metrics: Determine which metrics you'll track throughout migration. Include all categories: DORA, technical, business, organizational.
•Implement Instrumentation: Ensure measurement capability exists. You may need to add logging, monitoring, or tracking before you can measure.
•Collect Sufficient Data: Measure for long enough to account for variability. 3 months minimum; ideally 6+ months for seasonal businesses.
•Document Measurement Methodology: How exactly is each metric calculated? Document precisely so future measurements are comparable.
•Account for Context: Note any unusual circumstances during baseline period (incidents, reorgs, market changes) that might affect data.
•Get Stakeholder Agreement: Have leadership agree that baseline is valid. This prevents later disputes about starting point.

Example Baseline Documentation
Metric	Baseline Value	Measurement Period	Data Source	Notes
Deployment Frequency	2.3 per month (monolith)	Jan-Jun 2023	CI/CD pipeline logs	Bi-weekly release train, some hotfixes
Lead Time for Changes	18 days median	Jan-Jun 2023	Jira ticket data	Includes 5-day testing cycle
Change Failure Rate	28%	Jan-Jun 2023	Incident reports	Higher during Q2 due to rushed release
MTTR	3.5 hours median	Jan-Jun 2023	PagerDuty	Excludes 2 major incidents (outliers)
Infrastructure Cost	$145K/month	Jan-Jun 2023	AWS Cost Explorer	Includes over-provisioning for peaks
Developer NPS	+18	Jun 2023	Quarterly survey	34 respondents; good response rate

Don't Skip Baselines

Many migrations skip baseline establishment in their eagerness to start. This is a critical mistake. Two years into migration, when executives ask 'Was this worth it?', you'll have no answer. Baseline data is easy to collect now, impossible to collect later. Make it a Phase 0 requirement.

Dashboards and Visibility

Metrics are only valuable if people see them. Dashboards make metrics visible, accessible, and actionable. Different audiences need different views.

Dashboard Strategy:

Dashboard Types by Audience
Dashboard	Audience	Key Content	Update Frequency
Executive Summary	C-suite, Board	High-level progress, ROI, major risks, timeline status	Monthly
Migration Progress	All stakeholders	Service status, traffic split, milestones, blockers	Weekly
Technical Health	Engineering leadership	DORA metrics, service health, coupling indicators	Real-time
Team Dashboard	Individual teams	Their services' metrics, deployment history, incidents	Real-time
Cost Tracking	Finance, Ops	Infrastructure costs, trend, projections	Weekly/Monthly

DashboardDesign.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
// Migration Dashboard Configuration
 
interface DashboardConfig {
  name: string;
  audience: string[];
  refreshRate: string;
  panels: DashboardPanel[];
}
 
interface DashboardPanel {
  title: string;
  type: 'metric' | 'chart' | 'table' | 'gauge' | 'status';
  position: { row: number; col: number; width: number; height: number };
  dataSource: string;
  config: Record<string, any>;
}
 
// Executive Dashboard Configuration
const executiveDashboard: DashboardConfig = {
  name: 'Migration Executive Summary',
  audience: ['CTO', 'VP Engineering', 'CFO'],
  refreshRate: 'daily',
  panels: [
    {
      title: 'Migration Progress',
      type: 'gauge',
      position: { row: 1, col: 1, width: 4, height: 2 },
      dataSource: 'migration_progress',
      config: {
        metric: 'percent_complete',
        thresholds: [25, 50, 75, 100],
        colors: ['red', 'orange', 'yellow', 'green'],
      },
    },
    {
      title: 'Traffic Distribution',
      type: 'chart',
      position: { row: 1, col: 5, width: 4, height: 2 },
      dataSource: 'traffic_metrics',
      config: {
        chartType: 'stacked-area',
        series: ['monolith', 'microservices'],
        timeRange: '90d',
      },
    },
    {
      title: 'Key Metrics vs Baseline',
      type: 'table',
      position: { row: 1, col: 9, width: 4, height: 2 },
      dataSource: 'comparison_metrics',
      config: {
        metrics: ['deploymentFrequency', 'leadTime', 'mttr', 'cfr'],
        showBaseline: true,
        showTarget: true,
        showTrend: true,
      },
    },
    {
      title: 'Investment & ROI',
      type: 'metric',
      position: { row: 3, col: 1, width: 4, height: 2 },
      dataSource: 'financial_metrics',
      config: {
        metrics: [
          { name: 'Total Investment', format: 'currency' },
          { name: 'Benefits Realized', format: 'currency' },
          { name: 'Current ROI', format: 'percent' },
          { name: 'Projected 3Y ROI', format: 'percent' },
        ],
      },
    },
    {
      title: 'Timeline Status',
      type: 'status',
      position: { row: 3, col: 5, width: 4, height: 2 },
      dataSource: 'milestone_status',
      config: {
        showUpcoming: 3,
        showCompleted: 3,
        showRisks: true,
      },
    },
    {
      title: 'Top Risks',
      type: 'table',
      position: { row: 3, col: 9, width: 4, height: 2 },
      dataSource: 'risk_register',
      config: {
        filter: { status: 'active' },
        sort: { field: 'severity', order: 'desc' },
        limit: 5,
        columns: ['risk', 'severity', 'mitigation', 'owner'],
      },
    },
  ],
};
 
// Real-time Engineering Dashboard
const engineeringDashboard: DashboardConfig = {
  name: 'Migration Technical Health',
  audience: ['Engineering Teams', 'SRE', 'Architects'],
  refreshRate: 'real-time',
  panels: [
    {
      title: 'DORA Metrics',
      type: 'metric',
      position: { row: 1, col: 1, width: 12, height: 1 },
      dataSource: 'dora_metrics',
      config: {
        metrics: [
          { name: 'Deployment Frequency', target: '> 1/day', showTrend: true },
          { name: 'Lead Time', target: '< 1 day', showTrend: true },
          { name: 'Change Failure Rate', target: '< 15%', showTrend: true },
          { name: 'MTTR', target: '< 1 hour', showTrend: true },
        ],
        performance: 'elite',  // Show performance band
      },
    },
    {
      title: 'Service Health Grid',
      type: 'status',
      position: { row: 2, col: 1, width: 8, height: 3 },
      dataSource: 'service_health',
      config: {
        layout: 'grid',
        metrics: ['availability', 'latency', 'errorRate'],
        alerts: true,
      },
    },
    {
      title: 'Recent Deployments',
      type: 'table',
      position: { row: 2, col: 9, width: 4, height: 3 },
      dataSource: 'deployment_log',
      config: {
        limit: 20,
        columns: ['service', 'time', 'version', 'status'],
        highlightFailures: true,
      },
    },
    {
      title: 'Active Incidents',
      type: 'table',
      position: { row: 5, col: 1, width: 6, height: 2 },
      dataSource: 'incidents',
      config: {
        filter: { status: 'active' },
        columns: ['service', 'severity', 'duration', 'owner'],
      },
    },
    {
      title: 'Dependency Health',
      type: 'chart',
      position: { row: 5, col: 7, width: 6, height: 2 },
      dataSource: 'dependency_graph',
      config: {
        chartType: 'network',
        highlightIssues: true,
        showLatency: true,
      },
    },
  ],
};

Make Dashboards Accessible

Put dashboards on monitors in common areas. Send weekly email summaries with dashboard links. Make every team meeting start with a dashboard glance. Visibility creates accountability and awareness. If metrics are hidden in a tool only specialists access, they won't influence behavior.

Summary: Measurement Drives Success

Measurement transforms microservices migration from an act of faith into an evidence-based journey. With proper metrics, baselines, dashboards, and communication, organizations can objectively assess progress, justify investment, and continuously improve their approach.

Key Takeaways

•Measurement enables critical capabilities — Progress verification, investment justification, problem detection, decision support, and stakeholder communication all depend on metrics.
•Track multiple metric categories — Business value, technical health, and organizational metrics together provide a complete picture.
•DORA metrics are the industry standard — Deployment frequency, lead time, change failure rate, and MTTR are validated predictors of software delivery performance.
•Add migration-specific metrics — Traffic distribution, service independence, and coupling indicators track migration-specific progress.
•Connect to business outcomes — Technical metrics must translate to business value (cost savings, time-to-market, reliability) to maintain executive support.
•Establish baselines before starting — Without baseline data, you cannot prove improvement. This is non-negotiable.
•Make metrics visible — Dashboards for different audiences, placed where people see them, drive awareness and accountability.
•ROI takes time — Expect negative ROI during migration. Track trends and projected ROI based on accelerating benefits.

Module Complete: Migration Planning

Congratulations! You've completed the Migration Planning module. You now understand how to systematically plan a microservices migration: assessing and prioritizing components, organizing teams effectively, ensuring infrastructure readiness, creating realistic timelines, and measuring success throughout the journey. These skills separate thoughtful, successful migrations from expensive failures. Apply them rigorously to maximize your organization's chance of transformation success.