Validate the Migration

Move traffic only after behavior, security, performance, observability, and rollback gates pass.

Before cutover, follow these validation steps:

Replay captured events and compare expected outputs, errors, status codes, headers, body schema, object metadata, downstream writes, side effects, logs, and alarm behavior.
Run load and failure tests that cover p95/p99 duration, maximum duration, memory headroom, cold-start-sensitive paths, peak concurrency, backlog or queue age, retry storms, downstream rate limits, and capacity symptoms.
Test malformed payloads, duplicate events, poison messages, downstream unavailability, permission denial, secret rotation, network failure, timeout behavior, loop prevention, and rollback conditions.

Move traffic only after behavior, security, performance, observability, and rollback gates pass.

To cut over to OCI Functions, follow these steps:

Confirm that functional, performance, security, and operational validation gates have passed.
Record the cutover owner, rollback owner, success criteria, rollback triggers, and expected recovery time.
Freeze unrelated application changes during the cutover window.
Route a limited, observable portion of the workload to OCI Functions where possible.
Monitor business outputs, errors, timeouts, latency, throttling, backlog, and downstream failures.
Increase traffic only after the agreed observation period passes.
Stop the cutover and execute the rollback plan if a required success criterion fails.
Begin the next migration wave only after the application and operations owners accept the production results.

If percentage-based routing is unavailable, limit the initial exposure by trigger, bucket, queue, region, or another controlled workload boundary.

Confirm that the migrated workload meets its architecture, behavior, performance, security, and operations requirements.

To validate after the migration, follow these steps:

Workload role, source inventory, target architecture, alternatives, risk rating, service limits, and target invocation behavior are documented.
Trigger, dependency, security, networking, and operations inventories are complete enough for a reviewer to reproduce the target decision.
Captured events produce expected status codes, headers, body schema, object metadata, downstream writes, side effects, logs, and error behavior.
Each trigger has tests for payload format, retry, failure, ordering, batch behavior, idempotency, duplicate delivery, dead-letter or failure routing, and poison messages where applicable.
p95/p99 duration, maximum duration, memory headroom, cold-start-sensitive paths, peak concurrency, backlog or queue age, timeout count, throttle or 429 behavior, and downstream rate limits meet workload requirements.
Concurrency controls protect downstream systems and avoid retry storms or unbounded backlog growth.
Allowed service calls succeed and denied paths fail safely. Secrets are not present in source code, images, logs, environment dumps, CI output, stack traces, or error messages.
Required private and external dependencies are reachable through approved network paths. Logs, metrics, alarms, dashboards, traces, runbooks, rollback trigger, owner, steps, expected recovery time, and final approvals are complete before traffic moves.

Avoid these common migration design, integration, and operations failures.

Treating all Lambda functions the same: classify each function by role, trigger, dependencies, runtime behavior, traffic profile, and operational needs before choosing the target.
Choosing OCI Functions too early: validate payload, timeout, memory, dependency, invocation, concurrency, networking, and integration fit before refactoring code.
Assuming event payloads are identical: build an OCI handler adapter and replay captured source events before connecting production triggers.
Ignoring layers and native dependencies: package dependencies into the OCI function image or shared base image, then test image size, startup, native libraries, and dependency versions.
IAM translation is too broad: map observed runtime actions to least-privilege OCI policies and test denied paths, not just happy-path access.
Queue or stream semantics differ: design explicit idempotency, retry, partial failure, failure destination, ordering, and backpressure handling.
Object events cause loops: use separate input and output prefixes or filters and validate create, update, delete, retry, duplicate, and loop-prevention behavior.
Operations are postponed: enable logs, metrics, alarms, dashboards, runbooks, failure tests, and rollback checks before production traffic moves.