Why post-migration monitoring cannot wait The first weeks in AWS production after a migration represent a critical window where every undetected malfunction can affect end users or destabilize the business. Unlike an infrastructure that has been stable for years, the migrated environment accumulates several sources of risk: the configuration itself, still new, may contain deviations from the specifications; the transferred data may present subtle anomalies that only appear under real load; the interdependencies between services, possibly modified during the cloud architecture design, can cause cascading failures; and finally, the behavior of real users often differs from test profiles, revealing unexpected bottlenecks. Robust monitoring is not a cosmetic luxury but a production shield. The goal of post-migration monitoring is not to watch your entire infrastructure (that comes later, in the operations phase), but to validate that the migration itself succeeded and that the systems behave in line with the baselines established during the test phase. This means focusing on a restricted set of highly relevant metrics, calibrated on the values observed during load tests, and feeding actionable alerts that require immediate intervention. The discipline at this stage is to draw a clear line between migration incidents (abnormal, urgent) and normal performance variations (expected, to be monitored without panic). ## The 5 categories of critical metrics to define immediately Post-migration monitoring must be built around five distinct domains that, together, form a complete view of the migration's health. First, cloud infrastructure metrics, which validate that the provisioned AWS resources behave as expected: CPU consumption, memory, network bandwidth, storage usage, and disk access latency on your EC2, RDS, or managed service instances. These metrics serve as early detection of over-provisioning (uncontrolled costs) or under-provisioning (hidden degradation). Second, application metrics, which measure the behavior of the business code in AWS production: response time of critical API calls, error rate (5xx, 4xx), latency of key business transactions, and throughput of batch processing where applicable. These metrics must be calibrated on the baseline values from the performance tests in the preparatory phase. Third, data integrity metrics, which confirm that post-migration synchronization and reconciliation hold up: number of rows awaiting processing, count discrepancies between source and destination for critical data, and execution timestamps of scheduled synchronizations. Fourth, external dependency metrics, which detect whether calls to third-party services (partner APIs, databases left on-premise, authentication services) introduce abnormal latency. Fifth, AWS cost metrics, not to discover a surprise bill the following month, but to immediately detect drift: an application that suddenly starts generating ten times more DynamoDB requests, or an instance that scales itself up, generally signals a code or architecture malfunction to correct without delay. These five categories form the core of validation monitoring; any other metrics available in CloudWatch or your third-party observability tools remain interesting, but must not distract the team from the critical signals. ## Calibrating alert thresholds on your test baselines The classic pitfall in post-migration monitoring is setting arbitrary alert thresholds, often inherited from generic benchmarks or rules observed on the old infrastructure. This produces two symmetrical problems: either the thresholds are too low, and every minor variation triggers an alert (alert fatigue, a team that disables notifications), or they are too high, and real malfunctions go unnoticed. The correct method is to start from the real values observed during load and performance tests, run in an AWS environment identical to production. If, during your performance tests in AWS production, you measured that a critical API call executes in 150-200 milliseconds under nominal load, it is reasonable to set an alert threshold at 400-500 milliseconds. Likewise, if the CPU consumption observed during the peak-load test reaches 65 percent, an alert threshold at 80 percent leaves you a margin without exaggeration. For each critical metric, document at least three values: the nominal baseline (the normal observed value), the warning threshold (first cautionary alert), and the critical threshold (urgent alert). Use a progressive approach: for example, for a database's latency, you might define warning at +50 percent of the baseline (if the baseline is 50 ms, warning at 75 ms) and critical at +100 percent (100 ms). This approach ensures that you focus on real behavior changes, not on noise. Documenting these thresholds in a shared artifact (a spreadsheet shared with the team, an internal wiki page) lets everyone understand the alert ratio and adjust together if thresholds turn out to be too sensitive or too loose. Wait at least 24 to 48 hours of production operation before finalizing your thresholds: the first hours can be atypical (more numerous, nervous users, or access patterns distinct from the test). ## Structuring alerts to avoid fatigue and false positives An unwieldy alert is an alert that will not be heeded. If your team receives a hundred notifications a day, ninety of which are false positives or benign variations, it will disable the notifications or ignore the alerts. The correct structure of post-migration alerts must respect several principles. First, segment alerts by criticality and route them accordingly: critical alerts (a business API no longer responds, a database is unavailable) must trigger immediate escalation (SMS, call, urgent Slack) and be directed to the on-call person; warning alerts must be logged, sent to a dedicated Slack channel, and reviewed during a daily stand-up meeting without immediately blocking an engineer. Then, use alert aggregation to avoid notifying the same incident ten times. If you have 50 EC2 instances and 10 of them suddenly exceed a CPU threshold, that is not 10 independent alerts, but 1 aggregated alert "high CPU on 10 percent of production instances." Also introduce simple correlation logic: if the "high CPU" alert arrives at the same time as a "spike in API requests" alert, there is a probable explanation (increased load) and no need to panic; but if CPU stays low while API latency explodes, that is an abnormal signal that requires investigation. In the first weeks post-migration, adopt an iterative threshold-adjustment tactic: note each triggered alert, then at the end of the day the team triages (false positive? real malfunction? expected variation?) and adjusts the thresholds for the next day. This rapid feedback loop ensures that your monitoring converges toward a useful state in days, not weeks. For correlated metrics (e.g. if CPU rises, network I/O rises too, which is often normal), define composite alerts: only trigger a CPU alert if it is accompanied by an abnormal number of requests. Finally, put in place a temporary alert-silencing system for maintenance: a planned system update? Put the alerts in silent mode for that window, otherwise you will accumulate a hundred false alerts to dismiss manually. ## Validating data integrity under continuous monitoring After the data migration itself is complete and the data reconciled, data integrity monitoring does not stop: it simply changes in nature. During the migration and initial synchronization, you verified that all data had transited correctly (count comparisons, checksums, manual audits). During the post-migration phase, you watch that the data remains intact as production operations proceed. The integrity metrics to watch are: the number of rows pending in staging or queue tables (if any), which would signal a bottleneck in the synchronization pipeline; synchronization latency, that is, the gap between the moment data is created or modified at the source and the moment it appears fully at the destination (this gap must remain stable and predictable); the transformation or validation errors that your integration pipelines reject and log, which must stay at a negligible level; and finally, the inconsistencies detected by your business rules, for example a customer account with no address, or invoice amounts that do not match the sum of the line items. Each integrity metric must be fed by specific queries or scripts, executed on a regular schedule (hourly, or daily depending on criticality), and logged centrally. The advantage of having defined in the validation phase (in the parent page, the overall post-migration validation) the exact integrity rules to check is that you can automate them in monitoring without ambiguity. For example, if you validated that a customer account must always have at least an email and an address, schedule a SQL query that each day counts the accounts violating this rule, and alert if that count exceeds zero. This quickly detects either a persistent migration anomaly or a production bug that silently corrupts the data. Also integrate a coverage metric: what percentage of your data in AWS production is in sync with the source, and does that percentage remain stable? A drop spotted quickly allows a fix before users notice it. ## Organizing the monitoring shift: from validation to routine operations A mistake we often observe is believing that post-migration monitoring would resemble the monitoring of an infrastructure in normal operation, just a bit more attentive. This is not the case: validation and routine operations have different objectives. During validation (the first 3 to 6 weeks post-migration), your architecture/migration team is still heavily involved and available to diagnose and quickly correct any malfunction related to the migration itself. Your monitoring must therefore favor the early detection of drift from the test baselines, even if that means tighter thresholds and more alerts. You also expect to adjust AWS configurations, correct architectures, or re-validate procedures. Once you cross the boundary into routine operations (generally around week 6-8, when most migration risks are cleared and the team returns to its normal load), your monitoring must gradually transform: the thresholds widen to accept normal variations of a production infrastructure, the focus shifts from detecting migration anomalies toward detecting operational failures, and responsibility passes from the migration team to the DevOps or support team. The very structure of the alerts changes: in validation, you alert on "p95 API latency exceeds 500ms"; in operations, you alert on "all API calls return 5xx for 5 minutes." To perform this shift without loss of information, explicitly document when each metric will move from the strict monitoring phase to the relaxed monitoring phase, and validate this transition at a migration closure meeting. Put in place a formal handover between the migration team and the operations team, where you explain for each metric why it was defined, which incident it helped detect, and how it should evolve in the following weeks. This prevents the validation metrics from disappearing or being abandoned, while accepting that their role changes. Some metrics will remain critical forever (service continuity), others will become informational KPIs (a CPU spike is no longer an alert, but an interesting observation to correlate with business load). ## Tools and operational rollout of post-migration monitoring Concretely, which tool or which approach should you use to implement this monitoring? For an AWS infrastructure, native CloudWatch covers 80 percent of infrastructure monitoring needs (EC2, RDS, ELB, etc.) and its documentation builds directly on the concepts of alerts and thresholds. The additional cost is marginal if you stay reasonable on the number of custom metrics. The advantages of staying in the native AWS ecosystem: direct integration with your AWS services, a consistent API, and a single commercial relationship. If you already have a third-party observability tool (Datadog, New Relic, Prometheus + Grafana), the decision is more nuanced: these tools offer more flexibility for alert aggregation and event correlation, but require additional engineering to connect all your AWS sources. For an SMB or startup migrating for the first time, I recommend starting simple: CloudWatch for infrastructure metrics, and custom scripts (Lambda + CloudWatch Logs, or a cron task run on a small instance) for complex business metrics. Once your team knows what it wants to watch, you can then decide to invest in a more complete tool. Technically, here is the minimal rollout: for each critical metric identified, create a CloudWatch alarm or a custom check (via CloudWatch Agent, or Lambda) that collects the value every minute (or more often for critical ones), compares it to the threshold, and triggers an action if exceeded (sending an SNS notification, publishing a custom metric, calling a Lambda). Centralize all logs and metrics in CloudWatch Logs (or your third-party tool) with consistent tags (identifying the migration phase, the component involved, the severity), so that you can then build unified dashboards. Test the full alert chain (detection -> notification -> action) in production before declaring it operational: manually trigger a threshold and verify that the alert really reaches the on-call person. Document in a runbook what to do when each alert fires (e.g. "P95 API latency > 500ms": check the CPU of the instances, check the active queries in the database, check the external calls, apply action plan XYZ). This runbook prevents each engineer from reinventing the wheel when an alert fires and speeds up critical diagnostics.