Refactor Provider-Specific Boundaries

Preserve business logic while replacing AWS-specific integration code.

To refactor provider-specific boundaries, follow these steps:

  1. Extract business logic into provider-neutral modules. Add an AWS event parser only for replaying captured source events during comparison tests.
  2. Create an OCI adapter for the target invocation pattern: request/response, CloudEvent, queue message, stream record, object event, notification, or integration request.
  3. Replace direct AWS SDK calls with interfaces and implement OCI service calls behind those interfaces. Do the same for configuration, secret access, logging, metrics, and retry handling.
  4. Replay captured Lambda events and compare status codes, headers, response bodies, object metadata, downstream writes, side effects, error messages, and idempotency behavior.

Look for business logic to be separated from event parsing, SDK calls, IAM assumptions, logging, packaging, and retry handling.

Considerations: Avoid rewriting business logic at the same time as provider integration. Changing both makes equivalence testing harder.

Understand What OCI Provides

Identify which migration steps use standard OCI configuration and which require custom code.

Oracle Cloud Infrastructure provides services for function execution, API management, events, queues, scheduling, identity, networking, observability, and deployment. However, the migration might still require workload-specific changes, including:

  • Converting AWS event payloads into the input expected by the application
  • Replacing AWS SDK calls with OCI SDK calls
  • Recreating trigger, retry, ordering, and failure behavior
  • Translating IAM permissions and network access
  • Updating CI/CD pipelines and operational procedures

Before implementation, identify which steps use standard OCI configuration and which require custom code. Validate that distinction using a representative workload before estimating the wider migration.

Package and Deploy the OCI Function

Build the migrated function as a container image and deploy it to OCI Functions.

To package and deploy a function, follow these steps:

  1. Create or update the function project and func.yaml. Set memory and timeout from measured source behavior, not from defaults.
  2. Move former Lambda layer contents, native dependencies, runtime dependencies, certificates, and system packages into the image or a shared base image as appropriate.
  3. Track image size, dependency versions, native library compatibility, startup behavior, initialization work, and runtime behavior inside the container image.
  4. Build, push, deploy, and invoke the function with representative success and failure payloads before connecting production triggers.

Verify that the image builds, pushes, deploys, invokes successfully, and logs expected output without leaking secrets.

Considerations: Dependency packaging is often where hidden Lambda assumptions appear, especially with layers, native libraries, extensions, and embedded SDK versions.

Use a Repeatable Delivery Pattern

A production migration should use a version-controlled delivery process.

To use a repeatable delivery pattern, follow these steps:

  1. Store function code, configuration, tests, and infrastructure definitions together.
  2. Build and test a versioned function artifact.
  3. Scan the artifact and its dependencies.
  4. Promote the same tested artifact across environments.
  5. Provision or update OCI resources through Infrastructure as Code.
  6. Run smoke and integration tests after deployment.
  7. Retain the previous production artifact and configuration for rollback.

Use the existing CI/CD platform where practical. Do not require a tooling change unless it is necessary for the OCI Functions architecture.

Migrate Triggers and Integrations

Re-create the required invocation behavior in OCI.

To migrate triggers and integrations, follow these steps:

  1. For HTTP workloads, compare authentication, method, path, headers, query strings, body schema, status codes, error body, payload size, timeout, latency, and caller retry behavior.
  2. For object events, compare event schema, object metadata, namespace, bucket and prefix filtering, create/update/delete behavior, retry behavior, duplicate events, idempotency, and loop prevention between input and output paths.
  3. For queues and streams, design explicit handling for batch size, ordering, partial failure, visibility or retry behavior, DLQ or failure destination, poison messages, backpressure, duplicates, throughput, and replay.
  4. For schedules, notifications, logs, and integration flows, verify invocation type, latency, retry count, failure routing, fanout behavior, filtering, and observability.

Validate that each trigger has a documented OCI target pattern and passing tests for normal, failure, retry, and duplicate-delivery scenarios.

Considerations: Do not assume an AWS event source mapping has a direct OCI substitute. Preserve required behavior, not the AWS control name.

Common Lambda Trigger Patterns

The following mappings are starting patterns for an OCI Functions migration.

Validate the required behavior before implementation:

AWS pattern OCI Functions starting pattern Items to validate
API Gateway to Lambda OCI API Gateway to OCI Functions Routes, methods, authentication, request and response formats, payload limits, timeouts, status codes, and synchronous error behavior
EventBridge to Lambda OCI Events to OCI Functions for OCI service events; use the applicable OCI event-routing service for broader routing requirements Event coverage, filters, schemas, delivery behavior, retries, and replay requirements
SQS to Lambda Oracle Cloud Infrastructure Queue through OCI Connector Hub to OCI Functions Batch size, visibility timeout, at-least-once delivery, ordering, duplicate handling, poison messages, and failure recovery
S3 events to Lambda OCI Object Storage events through OCI Events to OCI Functions Event schema, filters, duplicate delivery, object permissions, retry behavior, and downstream side effects
Scheduled events to Lambda OCI Resource Scheduler to OCI Functions Schedule expression, time zone, input payload, timeout, overlapping executions, and success or failure destinations

Do not assume that AWS and OCI services have identical behavior. Validate the behavior required by each workload before implementation.

Preserve Trigger and Failure Behavior

Document and test the behavior required for every migrated trigger.

To preserve trigger and failure behavior, follow these steps:

  1. Document and test the following for every migrated trigger:
    • Whether delivery is synchronous or asynchronous
    • Retry owner, retry interval, and maximum attempts
    • Delivery guarantees and possible duplicate events
    • Ordering requirements
    • Idempotency behavior
    • Batch and partial-failure behavior
    • Visibility timeout or acknowledgement behavior
    • Poison-message handling
    • Failure or dead-letter destination
    • Replay and recovery procedure
  2. Do not assume that similar AWS and OCI services have identical delivery or failure behavior.
  3. Where duplicate delivery is possible, design the function to process repeated events safely.

For detached OCI Functions invocations, success and failure records can be sent to OCI Queue, OCI Streaming, or OCI Notifications destinations. This behavior is specific to detached invocations and should not be described as a universal replacement for every AWS dead-letter queue pattern.

Configure IAM, Secrets, and Networking

Translate runtime behavior into least-privilege OCI access and approved network reachability.

To configure OCI Identity and Access Management (IAM), secrets, and networking, follow these steps:

  1. Map each source action to an OCI action, resource, and compartment. Avoid broad policies unless the workload truly requires them and reviewers approve.
  2. Use dynamic groups and resource principals for runtime access to OCI resources. Test both allowed and denied paths, including wrong compartment, wrong bucket, wrong secret, and missing policy cases.
  3. Move secrets to OCI Vault or an approved pattern. Confirm no secret values appear in source code, images, logs, environment dumps, CI output, stack traces, or error messages.
  4. Validate route rules, security rules, service gateway or NAT behavior, private endpoints, DNS, TLS trust, external allowlists, and downstream connection limits.

Validate that allowed service calls succeed, denied paths fail safely, and required network paths are reachable without exposing unauthorized paths.

Considerations: IAM translation should start from observed runtime behavior, not from AWS policy names or broad managed policies.

Recreate Observability and Operations

Ensure production owners can detect, diagnose, and recover from failures.

To recreate observability and operations, follow these steps:

  1. Emit logs with correlation ID, request ID, trigger ID, object or message identifier, status, duration, retry count, sanitized error detail, and downstream dependency result.
  2. Confirm metrics and alarms for invocation count, duration, error rate, timeout count, throttling or capacity symptoms, DLQ or failure count, queue age or backlog, detached delivery results, and downstream failures.
  3. Create dashboards or approved views for health, latency, errors, capacity, trigger backlog, and dependency status.
  4. Update runbooks with invoke tests, log queries, alarm response, escalation contacts, rollback trigger, rollback steps, and expected recovery time.

Verify that production operators can observe and troubleshoot the migrated function before traffic moves.

Considerations: A migration is not production-ready if only the function works. Operators must be able to detect and recover from a failed trigger, secret, network path, or downstream dependency.