OCI Streaming and Queue to STACKIT

The migration in six steps

A demo estate of five resources, assessed on 4 November 2026, gives the order. The steps are the ones your team carries out; the run supplies the targets, classes and dependencies.

1. 01

   1. Inventory queues, streams and clients

   List every producer and consumer with the protocol it uses. OCI Queue offers a REST API and the STOMP protocol; OCI Streaming is compatible with most Kafka APIs. The client protocol decides how much application code changes.

2. 02

   2. Choose the broker for each stream

   Streams land on a self-managed Kafka-compatible broker on SKE, or the messaging design changes to RabbitMQ. The run records the first as the target; its reason names the second as the alternative.

3. 03

   3. Build the SKE cluster on a supported version

   Pick a Kubernetes version the report marks suitable. Plan the broker with the partition count and retention of the source streams, which the run lists as settings left to you.

4. 04

   4. Create the RabbitMQ instance and queues

   Each OCI queue becomes a queue on STACKIT RabbitMQ. Recreate retention, redelivery and dead-letter behaviour with RabbitMQ features and test them.

5. 05

   5. Move producers and consumers in a controlled order

   Messages in flight are drained before cutover. For streams, agree how consumers keep their position and how long both sides run side by side.

6. 06

   6. Retire the OCI side after the hold period

   Keep the OCI queues and streams until the rollback window ends. Delete them only after the agreed hold period (general practice).

A stream and its pool, assessed

Left: the pool and both streams in the input. Right: the decisions for the pool and the stream clicks as they stand in assessment.json; orders is assessed the same way. The streams are mapped; the stream pool is not in the catalogue of this build and is left for your architects. assessment.json is written as a single line, so the pane shows selected fields of each unit, indented and nested as in the file, with the values unchanged.

resource "oci_streaming_stream_pool" "events" {
  compartment_id = var.compartment_id
  name           = "events"
}

resource "oci_streaming_stream" "orders" {
  name               = "orders"
  partitions         = 6
  retention_in_hours = 72
  stream_pool_id     = oci_streaming_stream_pool.events.id
}

resource "oci_streaming_stream" "clicks" {
  name               = "clicks"
  partitions         = 12
  retention_in_hours = 24
  stream_pool_id     = oci_streaming_stream_pool.events.id
}

[
  {
    "id": "oci_streaming_stream_pool.events",
    "result": {
      "class": "MANUAL_REVIEW",
      "confidence": "LOW",
      "reason": "oci_streaming_stream_pool is not in the knowledge base catalogue; an architect has to decide the target. Nothing of this resource is assessed or drafted (unknown source type)."
    }
  },
  {
    "id": "oci_streaming_stream.clicks",
    "result": {
      "class": "CONTAINERIZE",
      "confidence": "MEDIUM",
      "target": {
        "service": "a self-managed Kafka-compatible broker on SKE"
      },
      "reason": "STACKIT has no managed Kafka service. The stream moves to a self-managed broker on SKE, or the messaging design changes to RabbitMQ."
    }
  }
]

• CONTAINERIZE, medium confidence

  The stream becomes a workload you run on SKE. The report names a self-managed Kafka-compatible broker, with an SKE cluster as the STACKIT resource behind it.

• The pool is manual

  oci_streaming_stream_pool is a MANUAL_REVIEW unit with no target. Oracle describes a pool as the grouping of streams that holds any shared Kafka or security settings; those settings are yours to carry over.

• Partitions and retention are carried by you

  name, partitions, retention_in_hours and stream_pool_id are the four critical settings the report lists for the stream. The demo sets 12 partitions and 24 hours for clicks, 6 and 72 for orders.

Two queues, one with dead-lettering, assessed

The queue named jobs moves a message to a dead letter queue after 5 delivery attempts; jobs_dead is a second, ordinary queue. assessment.json is written as a single line, so the pane shows selected fields of each unit, indented and nested as in the file, with the values unchanged. The demo sets 7 days (604800 seconds) on jobs_dead, the maximum retention Oracle documents for a queue.

resource "oci_queue_queue" "jobs_dead" {
  compartment_id       = var.compartment_id
  display_name         = "jobs-dead"
  retention_in_seconds = 604800
}

resource "oci_queue_queue" "jobs" {
  compartment_id                   = var.compartment_id
  display_name                     = "jobs"
  retention_in_seconds             = 345600
  visibility_in_seconds            = 60
  timeout_in_seconds               = 20
  dead_letter_queue_delivery_count = 5
}

[
  {
    "id": "oci_queue_queue.jobs",
    "result": {
      "class": "REPLATFORM",
      "confidence": "MEDIUM",
      "target": {
        "service": "STACKIT RabbitMQ"
      },
      "reason": "An OCI queue becomes a queue on STACKIT RabbitMQ. Clients change protocol, and messages in flight are drained before cut-over."
    }
  },
  {
    "id": "oci_queue_queue.jobs_dead",
    "result": {
      "class": "REPLATFORM",
      "confidence": "MEDIUM",
      "target": {
        "service": "STACKIT RabbitMQ"
      },
      "reason": "An OCI queue becomes a queue on STACKIT RabbitMQ. Clients change protocol, and messages in flight are drained before cut-over."
    }
  }
]

• REPLATFORM to RabbitMQ

  Both queues become queues on a STACKIT RabbitMQ instance. The reason says clients change protocol and messages in flight are drained before cutover.

• Behaviour settings left to you

  Retention, visibility timeout, polling timeout and the delivery count before dead-lettering are listed as settings you carry over. The run does not translate them.

• Mind the dead-letter link

  In the input, jobs sets a delivery count of 5, but nothing in the Terraform of the demo references jobs_dead; the pairing exists only in the naming. Make it explicit in the RabbitMQ design.

How the messaging estate maps

Classes and targets as the run decided them. The queue pair and the stream pair are two units each, one row each here.

The SKE versions you can land on

The report states each SKE version with its dates, read from the STACKIT pages on 3 November 2026 and not vouched for after 1 February 2027. These are the rows as written in engineering/architect-report.md.

| Version | State | Released | Deprecated | Expires | Production suitability | Upgrade action | Migration timing risk |
|---|---|---|---|---|---|---|---|
| 1.36 | SUPPORTED | 2026-08-27 | not stated | 2027-06-09 | SUITABLE | PLAN | LOW |
| 1.35 | UNKNOWN | not stated | not stated | 2027-02-10 | UNKNOWN | UNKNOWN | UNKNOWN |
| 1.34 | EXPIRED | 2025-12-16 | 2026-08-28 | 2026-10-14 | NOT_SUITABLE | MANDATORY_UPDATE_APPLIES | HIGH |
| 1.33 | EXPIRED | 2025-07-29 | 2026-06-09 | 2026-06-10 (sources disagree: 2026-07-08) | NOT_SUITABLE | MANDATORY_UPDATE_APPLIES | HIGH |
| 1.32 | EXPIRED | not stated | 2026-02-20 | 2026-04-15 | NOT_SUITABLE | MANDATORY_UPDATE_APPLIES | HIGH |

• Land on 1.36

  1.36 is supported, with a planned upgrade and an expiry on 9 June 2027. The STACKIT lifecycle page lists the same expiry.

• 1.35 is not assessed

  The run marks it UNKNOWN and says there is no date evidence, so it is not assessed, although its row carries an expiry of 10 February 2027, the same date the STACKIT lifecycle page lists. Either way it ends four months before 1.36; do not land on it.

• Expired versions are not an option

  1.32, 1.33 and 1.34 are expired; the mandatory update applies. A self-managed broker on SKE moves with each cluster upgrade, so plan broker upgrades with the cluster's.

Decisions the architect owns

• Kafka-compatible broker or RabbitMQ for streams

  A stream keeps messages after they are read and lets consumers replay inside the retention time; ordering is per partition. A queue message is gone once the consumer deletes it. If your consumers replay, RabbitMQ is a redesign, not a swap.

• Who runs the broker

  A broker on SKE is yours to size, secure, upgrade and back up. State the on-call owner and the upgrade cadence in the plan.

• How queue semantics are reproduced

  OCI Queue has a visibility timeout and a maximum delivery count; RabbitMQ redelivers unacknowledged messages and offers message expiry and dead-letter exchanges (RabbitMQ features, not STACKIT documentation: check them on the plan version you choose).

• Client protocol

  The STACKIT RabbitMQ page lists MQTT and STOMP as plugins and does not name AMQP on that page. Confirm which protocol your clients will speak before the build.

• Cutover order and the replay window

  Producers, consumers and the dual-run period are your design; the run gives only dependency waves (queues and pool in wave 1, streams in wave 2).

Questions integration teams ask

Sources

• Oracle docs: Streaming overview
• Oracle docs: Queue overview
• STACKIT docs: Architecture of RabbitMQ
• STACKIT docs: SKE Kubernetes version lifecycle