Event Endpoint Management continues to be enhanced

Event Endpoint Management continues to be available and enhanced as part of IBM's integration platforms.

End of Marketing announcement for IBM Event Automation

Event Streams and Event Processing are deprecated and no enhancements will be provided. Support and security fixes will be provided in line with published support lifecycle policies. Future event-driven solutions that make use of Apache Kafka and Apache Flink will be delivered by IBM Confluent.

For more information, see how you can plan your transition.

Decommissioning Event Streams

Remove your Event Streams instance and any remaining infrastructure after all components and applications are validated on Confluent Platform.

Important: Do not start this phase until validation is complete. Until Event Streams is deleted, you can still roll back to it.

Decommissioning checklist

Review the following checklist before and during the decommissioning process:

  • Complete all checks in the validation page before starting decommissioning.
  • Confirm that no client applications are connecting to Event Streams. Check broker connection metrics and consumer groups for any remaining activity.
  • Confirm that all topics required for migration have been promoted and validated, and that no mirror topics are still active on the ClusterLink.
  • If tiered storage is enabled, archive the Event Streams object-storage data before deleting or releasing the storage.
  • Delete the Event Streams instance and the custom resources managed by it.
  • Remove the Event Streams operator if no other Event Streams instances remain.
  • Release the infrastructure that was used only by Event Streams, including persistent volume claims (PVCs), routes, load balancers, firewall rules, and the source object storage bucket after confirming the archive.
  • Update runbooks, monitoring configurations, and on-call references to reflect Confluent Platform only.

Decommissioning steps

Complete the decommissioning tasks in the following order:

  1. Verify that Event Streams is idle: Confirm that no producers, consumers, connectors, or REST clients are connected. Broker metrics must show zero client traffic before you proceed.
  2. Remove MirrorMaker 2: If your deployment used MirrorMaker 2 for geo-replication, remove the KafkaMirrorMaker2 custom resource and any associated MirrorMaker 2 resources after confirming that the replacement Cluster Linking or Replicator flows on Confluent Platform are healthy with zero lag.
  3. Delete the ClusterLink: Delete the ClusterLink custom resource or stop the Confluent Replicator connector. Confirm that no mirror topics remain active before deleting the cluster link.
  4. Archive before deleting: If tiered storage is enabled, archive the Event Streams object-storage data and any other operational data that you need to retain before deletion.
  5. Delete Event Streams resources: Remove the EventStreams custom resource and the custom resources managed by it, and wait for the deletion to complete.
  6. Release infrastructure: Delete the PVCs, remove OpenShift routes, load balancers, and firewall rules used only by Event Streams, and delete the source object-storage bucket after confirming the archive.

Post-decommissioning tasks

  • Kafka version upgrades and any Confluent Platform configuration changes that were deferred during the migration can now be planned and carried out as separate activities.
  • Remove any Event Streams-specific tools, such as the kubectl es CLI plug-in and dashboards, and standardize on the Confluent CLI and Confluent Control Center.

Migration is complete when Event Streams and all associated infrastructure are removed and all components and applications are running on Confluent Platform.