Migrating Kafka from virtual machines to Kubernetes with Strimzi starts with the inventory
A team running a VM-based Kafka cluster that wants to move to Kubernetes with Strimzi should treat the move as a re-platform: a second cluster built on Strimzi, bridged by MirrorMaker 2, followed by a controlled switch of producers and consumers. It is not an in-place upgrade of the existing brokers. The first deliverable is therefore a complete inventory of what the current cluster does, because every item in that inventory becomes a decision in the new design. The Kafka project itself is released under the Apache License 2.0 (SPDX: Apache-2.0) and has no paid edition, so the cost of this work lies in engineering, testing and operations rather than in licensing the software.
The inventory has four parts. Start with brokers and controllers: confirm the Kafka version, whether the cluster already runs in KRaft mode, and how each node is configured, including storage paths, listeners and JVM settings. Then list every topic with its partition count, replication factor, retention and compaction settings, since these become the topic custom resources in the new cluster. Next, record every principal, ACL, and SCRAM or OAUTHBEARER credential, along with the TLS certificates in use. Finally, map every producer, consumer group and Kafka Connect connector to its owning team and its bootstrap address. Clients that are missing from this list are the usual cause of a failed cutover.
The effort is driven by three things: how many topics, principals and clients the inventory contains, how much of the security model lives outside Kafka (for example in certificate authorities, identity providers or network rules), and how many of those clients the owners can switch within a planned window. Ask the Strimzi project and your own platform team to confirm which Kafka version and Strimzi release you will target, and check the supported upgrade path for your current version before committing to a design. Agree on the scope in writing, including which systems are out of scope for the migration, before any node pool or topic definition is written.
What maps from VM Kafka to Strimzi and what does not
This table compares how each part of a VM-based Kafka cluster is represented when it moves to Strimzi on Kubernetes. Read the left column as your current setup and the right columns as what changes, what carries over and what you must rebuild or confirm. The main takeaway is that the Kafka protocol and data model stay the same, while identity, storage, networking and client addresses are rebuilt and need their own cutover plan.
| Area | On VMs today | On Strimzi |
|---|---|---|
| Brokers and controllers | Separate processes or hosts, often configured by hand in server.properties files | Declared as node pools with roles for brokers, controllers or both, managed by the Strimzi operator |
| KRaft metadata mode | Required for Kafka 4.x, so ZooKeeper-era clusters must migrate to KRaft first | KRaft is the metadata mode used, so confirm the Strimzi and Kafka versions you target support your migration path |
| Storage | Log directories on host disks, often mounted by path | Persistent volume claims per node pool; storage class, size and retention of volumes must be planned before deployment |
| Network identity | Stable host names and IP addresses per broker | Pod names and advertised listeners must be configured so clients reach each broker at a stable address |
| Client bootstrap addresses | Host names or IPs listed in client configuration | Service or ingress addresses change, so every producer, consumer and connector needs an updated bootstrap list |
| Topics | Created with kafka-topics.sh or automation scripts | Declared as KafkaTopic custom resources and reconciled by the operator, so partition and config settings live in version control |
| Users and ACLs | SCRAM credentials and ACLs managed with CLI tools or scripts | Declared as KafkaUser custom resources, with authentication and authorization settings defined per user |
| Listeners and TLS | Listeners and certificates configured per broker, often with manually rotated keys | Listeners defined in the Kafka custom resource, with certificates managed by the operator; confirm rotation behavior for your version |
| MirrorMaker 2 and replication | Often run as standalone processes or Connect workers beside the source cluster | Run as declared resources in Kubernetes; offsets and ACLs replication must be checked against your existing setup before cutover |
Documented tools for moving data and configuration
Moving a VM-based Kafka cluster onto Strimzi splits into three jobs: copying data and consumer state, recreating declared configuration as Kubernetes resources, and exporting what already exists. Each path below documents a different part of that work, and none of them covers all of it, so plan the gaps before cutover.
MirrorMaker 2 for topic data
MirrorMaker 2 is built on Kafka Connect and replicates topics with their configuration, consumer groups with offsets, and ACLs between clusters while preserving partitioning. It is the documented route for moving records from the VM cluster to the Strimzi cluster while both run. Check that the source and target clusters can reach each other on every listener, that topic names will not collide, and that the mirrored ACLs match the security model you intend to keep on Kubernetes. Confirm the replication behavior for your Kafka version against the project's geo-replication guide.
Strimzi KafkaTopic resources
Strimzi's topic operator lets you declare topics as KafkaTopic custom resources, which gives topic partitions, replication factor and config a version-controlled home. Use this to recreate topics that MirrorMaker 2 will not create for you, or to reconcile topics that already exist on the target. Record the partition count and retention settings from the VM cluster before you export them, because changing partition counts later affects key-based ordering. Confirm the exact fields and operator behavior with the Strimzi documentation for your release.
Strimzi KafkaUser and ACL resources
Strimzi's user operator recreates principals as KafkaUser resources, with authentication and authorization declared alongside each user. Mirroring ACLs does not guarantee that the same principals, credential types or secret names exist on Kubernetes, so map each VM-era principal to a Strimzi user before switching clients. Be specific about what is not carried over: client passwords or certificates issued on the VMs will usually need to be reissued or rotated. Confirm the supported authentication types and ACL fields in the Strimzi user documentation.
Strimzi KafkaConnector resources
Kafka Connect connectors that ran on VMs can be declared as KafkaConnector resources once a KafkaConnect cluster exists on Kubernetes. This covers connector class, tasks and configuration, but not the state of the source system or the offsets stored by the old worker. Inventory every connector, its plugin version and any secrets it reads before you start. Pause source connectors during cutover to avoid duplicate writes, and confirm offset handling for each connector type with the Strimzi and connector documentation.
kubectl and GitOps export of existing definitions
Strimzi custom resources can be exported from the Kubernetes cluster with kubectl get and committed to a Git repository for review, which makes the target state reproducible. This does not read definitions from the VM cluster, so you still need a script or a manual inventory that produces the KafkaTopic, KafkaUser and KafkaConnector manifests from the existing broker configuration. Store manifests without secret values, keep credentials in a secrets store, and confirm the export and reconciliation behavior for your GitOps tool and Strimzi version.
Gaps no documented tool covers
No single tool moves everything: consumer group offsets may need translation between clusters, broker-level dynamic configs and JVM settings are not carried over automatically, and client bootstrap addresses must be changed in every application. Also list what the old cluster did informally, such as alerts, quotas and listener rules. Treat this as a checklist for the cutover runbook, and validate each gap with a test on a non-production copy. Ask the Strimzi and Kafka projects to confirm current coverage for your versions.
How the cutover sequence runs with a parallel run
The sequence moves a VM-based Kafka cluster to Strimzi in controlled stages, so producers and consumers can switch with a documented rollback path until the VMs are retired.
Inventory topics, clients, ACLs and offsets
The team lists every topic with its partition count, replication settings and retention, every producer and consumer group with its client version and bootstrap addresses, every ACL and SCRAM or TLS identity, and the committed offsets for each consumer group. Platform engineering and the application owners sign off on the list. The step is done when the inventory is reviewed against the live cluster and each client has a named owner and a planned switch window. Ask DeployOpen or your team to confirm which clients rely on features that need a specific Java runtime, since Kafka 4.0 and later require Java 17 for brokers and Connect.
Build the Strimzi cluster in a pilot environment
The team deploys Strimzi on a Kubernetes environment that matches the target, then defines the Kafka cluster with KRaft node pools for controllers and brokers, setting storage, listeners, authentication and authorization to match the VM design. Topics and users are recreated as custom resources in a test namespace. The step is done when a test client can produce, consume and authenticate against the pilot cluster and the configuration is stored in version control. The Kubernetes control plane and node versions should be confirmed against the project's version skew policy before this build begins.
Start MirrorMaker 2 replication from source to target
A MirrorMaker 2 deployment, running on Kafka Connect, replicates the selected topics from the VM cluster to the Strimzi cluster. It copies topic configuration, consumer group offsets and ACLs where the design requires them, and preserves partitioning. The team confirms the replication flows are running, lag is stable, and the replicated topic partition counts match the source. The step is done when the replicated data has been checked against source offsets for a representative set of topics. Only the replication design and its security settings should be checked here, because MirrorMaker 2 must reach both clusters under its own identity.
Validate consumer offsets and access on the target
Before any client moves, the team checks that the translated consumer group offsets on the target match the source positions closely enough to resume without duplicate or missed processing, and that every identity can authenticate and has only the ACLs it needs. Access tests cover each producer and consumer role, including denied cases. The step is done when a signed-off test record shows each group and identity passed on the target and each failure has been fixed and retested.
Switch consumers in stages
Consumers move first in groups, one application or team at a time, so that processing can be paused, drained and resumed on the target without changing producers. Each consumer switch is recorded with its offset position and monitored for lag and error rates. The step is done when every consumer group reads from the Strimzi cluster and the source cluster has no active consumers left for the migrated topics. Because consumers can read from a replicated topic while producers still write to the source, this stage keeps the parallel run in place for rollback.
Switch producers and stop replication for migrated topics
Producers are moved one service at a time to the Strimzi bootstrap address, and each change is checked for successful writes and steady consumer lag on the target. Once no producer writes to a topic on the VM cluster, the team stops the MirrorMaker 2 flow for that topic and confirms no data is still in transit. The step is done when the source topics show no new writes over an agreed observation period and the target holds the full set of production messages for each migrated topic.
Decommission the VMs after rollback windows close
The VM brokers and controllers are kept in a read-only or idle state for the rollback window agreed in the plan, with backups and configuration captured beforehand. When the window closes with no open incidents, the team removes the VMs, revokes their credentials and certificates, removes DNS entries and updates the runbook and inventory. The step is done when the VM cluster is retired, access is removed, and the post-migration record is filed. Ask for a written decommission checklist in any quote so ownership of each removal task is clear.
How MirrorMaker 2 keeps the VM and Kubernetes clusters in step
MirrorMaker 2 is the replication layer that carries the migration, and it runs as Kafka Connect source connectors that read from the VM cluster and write to the Strimzi cluster. Because MirrorMaker 2 is built on Kafka Connect, it replicates topics with their configuration, consumer groups with their committed offsets, and ACLs between the two clusters, and it preserves partitioning so that records keep the partition they were written to. That matters for keyed topics, where ordering per key depends on the same partition mapping. The team should confirm which of these artifacts it needs before cutover, especially ACLs, because the Strimzi KafkaUser resources must be written to match whatever access the VM cluster enforced.
Replication runs in one direction for the migration, from the source VM cluster to the target Kubernetes cluster. The team needs to check three things before switching any client. First, replication lag on every mirrored topic, measured as the gap between source and target end offsets, should be stable and close to zero under production traffic, not only during a quiet test window. Second, offset translation must be verified: consumer group offsets are copied with an offset mapping, so a consumer that resumes on the target should land at the correct position. Test this with a non-production consumer group and compare committed positions before trusting it for production groups.
Third, topic naming needs a plan. MirrorMaker 2 prefixes replicated topics with the source cluster alias by default, so a topic named orders on the source may appear as a differently named topic on the target. Clients that expect the original name will not find it unless the team either adjusts the replication naming policy or renames topics in the Strimzi KafkaTopic resources. Decide this in writing for every topic, and confirm the exact naming behavior against the version of MirrorMaker 2 your Strimzi release ships, because the default behavior and the available policies are documented in the Kafka geo-replication documentation.
Choosing the authentication model before the cutover
Keeping SCRAM is the path with the smallest client change. Kafka supports SCRAM-SHA-256 and SCRAM-SHA-512 as SASL mechanisms, so applications that already send a username and password can usually keep their configuration and only change the bootstrap address and the trust store. On Strimzi, SCRAM users are declared as KafkaUser custom resources with the scram-sha-512 authentication type, and the generated password is stored in a Kubernetes Secret that the operator creates. Confirm whether your current credentials live in the VM-era metadata or in an external store, because they must be recreated in the new cluster rather than copied.
- Client change: Usually limited to
sasl.mechanism, the JAAS login configuration and the new bootstrap servers. - Strimzi resource: A
KafkaUserper application, with the password held in a generated Secret. - Credential handling: Passwords must be rotated or reissued, and you should decide who can read those Secrets.
- Authorization: ACLs are written to the KRaft metadata log with the StandardAuthorizer, so each user needs its ACLs recreated.
- Test: Each application must authenticate, produce, consume and fail correctly when given a wrong password.
Before cutover, check that every application's SCRAM user, ACL set and Secret reference matches the inventory you exported from the VM cluster.
Mutual TLS, where clients present certificates that the broker verifies, removes shared passwords from application configuration. Kafka documents SSL as a supported client and broker authentication path, and the security overview explains that SSL covers both encryption and authentication. On Strimzi, the Cluster Operator can manage broker certificates, and a KafkaUser with the tls authentication type generates a client certificate. This option changes every client's keystore and key handling, so it has the largest application impact of the options in this section.
- Client change: Each client needs a key store, a trust store and a rotation procedure for its certificate.
- Strimzi resource: A
KafkaUserwithtlsauthentication, plus the cluster CA certificates the operator publishes. - Certificate lifecycle: Plan renewal of both the cluster CA and the user certificates, and confirm how the operator handles renewal windows in your release.
- Principal mapping: Confirm how the certificate distinguished name maps to the principal that ACLs reference.
- Test: Verify certificate expiry alerts, rejection of an untrusted certificate and a successful renewal without a broker restart.
Check with your security team whether an internal certificate authority is required, because that decision drives who signs client certificates and how revocation is handled.
OAUTHBEARER and GSSAPI (Kerberos) are documented SASL mechanisms that fit organizations already running an OAuth or OpenID Connect identity provider or a Kerberos realm. These options centralize identity and remove long-lived secrets from client configuration, but they depend on the identity platform being available and correctly configured for Kafka clients. Confirm the exact configuration keys, token validation settings and the Strimzi fields for your Strimzi and Kafka versions in the Strimzi documentation before you commit, because support details change between releases.
- Client change: Clients need token acquisition or a Kerberos ticket, with JAAS or client callback settings updated.
- Strimzi resource: Listener authentication configuration on the
Kafkaresource, plus the identity provider settings the operator passes to brokers. - Dependency: Identity provider uptime, clock synchronization and realm or issuer configuration become cutover risks.
- Authorization: Principals from the identity provider must match the names used in ACLs on the StandardAuthorizer.
- Test: Token expiry and refresh, a Kerberos ticket renewal, and a deliberate outage of the identity provider to confirm the failure mode.
If the identity platform is not already in production for these workloads, treat this option as a separate project and compare it with the SCRAM or mutual TLS path.
Kafka security is optional, so a cluster can run with unsecured listeners or mix secured and unsecured listeners on different ports. A VM cluster that grew over time may still expose a plaintext listener to some clients. Moving to Strimzi is the moment to decide which listeners remain, because each unsecured listener is an open path around your authorization model. Make the decision explicit in the Kafka resource listener definitions and in the change record, rather than letting the new cluster inherit whatever the old one allowed.
- Inventory: List every client that connects without TLS or SASL, using broker logs and listener metrics from the VM cluster.
- Listener design: Define each Strimzi listener with its type, TLS setting and authentication, and remove listeners nobody needs.
- Authorization default: Unless
allow.everyone.if.no.acl.foundis set to true, resources without ACLs are restricted to super users, so confirm that setting explicitly. - Super users: Limit the super user list and document who holds it.
- Test: Connect from each inventoried client to each new listener and confirm the expected accept or reject result.
Record the decision for each listener and the owner who approved it before the first client is switched.
What drives the effort and cost of the move
This table lists the factors that change the size of a VM-to-Strimzi move, whether each one is paid once or recurs, and what to request in a written scope. Use it to compare your estate against the drivers before asking a partner or your own team for a plan.
| Driver | Why it changes effort | One-time or recurring | What to ask for in a written scope |
|---|---|---|---|
| Topic and partition count | Each topic and partition must be declared as a KafkaTopic resource and its replication and retention checked, and MirrorMaker 2 must copy every one. | One-time (recreation and copy); recurring when new topics are added to the platform | A full topic inventory with partition counts, replication factors, retention and cleanup policies, and the list of topics excluded from copying |
| Number of client applications and languages | Each client needs new bootstrap addresses, TLS material and credentials, and each language library may need its own configuration review. | One-time for cutover; recurring for new applications onboarded later | A list of every producer and consumer with language, client library version, and the owning team for each |
| Consumer offset complexity | Consumer groups must be replicated and their offsets translated so consumers resume at the right point, and groups with unusual offset states need extra verification. | One-time per cutover wave | The consumer group inventory, expected lag at cutover, and the approach for checking that offsets moved correctly |
| ACL and user volume | Each Kafka user and ACL must be rewritten as a KafkaUser resource, and the StandardAuthorizer rules must be confirmed to match the existing access model. | One-time conversion; recurring when access requests arrive | Counts of users, principals and ACL entries, the authentication mechanism in use, and the access test plan |
| Storage migration method | Data can be copied by mirroring between clusters or by restoring from storage, and each method has different downtime and validation work. | One-time | The chosen copy method, expected data volume per topic, and the validation step that compares message counts and checksums before switching |
| Network and DNS changes | New broker advertised listeners, load balancers or Kubernetes services change the addresses clients connect to, and firewall rules and DNS records must follow. | One-time for cutover; recurring if addresses change later | A network diagram of old and new listeners, DNS change plan, firewall change requests and the rollback address plan |
| Kubernetes platform readiness | Strimzi runs on a cluster that must already meet the Kubernetes version and skew rules, have etcd backups in place, and enforce the Pod Security Standards the brokers need. | One-time readiness work; recurring for platform upgrades | Confirmation of the Kubernetes version, the distribution in use, storage classes, backup coverage and the policy level applied to the Kafka namespace |
| Number of environments | Development, test, staging and production each repeat the migration steps, and differences between them often hide configuration errors. | One-time per environment; recurring for keeping environments aligned | Environment list with topology differences, the order of migration, and the acceptance criteria for each environment before production |
What usually goes wrong during a Kafka to Strimzi move
Most failed Kafka migrations to Strimzi fail at the edges: client addresses, consumer positions, access rules, versions, storage and the rollback window. Each card below names one of these risks, the step that prevents it, and what your own team should confirm before cutover.
Clients hard-coded to old bootstrap addresses
Applications often carry the VM brokers' hostnames or IPs in their configuration, in service registries or in secrets that nobody reviews. Once Strimzi exposes listeners through Kubernetes services, routes or load balancers, those addresses stop resolving or point at brokers that have been drained. Inventory every client's bootstrap.servers value, including batch jobs, Connect workers and monitoring agents, and plan a change window for each. Confirm with each owning team which configuration source they read at startup and whether a rolling restart is allowed.
Consumer offsets not translated before cutover
If consumer groups move without their offsets, consumers either reprocess large ranges or skip data. MirrorMaker 2 replicates consumer groups and their offsets, but the offset values on the target are only meaningful once the consumers are pointed at it and the checkpoints have caught up. Confirm checkpoint lag for each critical group before you stop producers on the source, and agree with application owners whether duplicate processing is acceptable for each sink.
ACLs missing on the new cluster
Authorization rules do not follow the topics automatically in every path. Under the StandardAuthorizer, resources without ACLs are restricted to super users unless allow.everyone.if.no.acl.found is set, so a consumer that worked on the VM cluster can be denied on Strimzi the moment it connects. Export the existing ACLs, map each principal to its Strimzi KafkaUser identity, and test every client in a non-production namespace before cutover. Confirm how your authentication mechanism maps principals, since the names may change.
Java and version gaps
Brokers and Connect require Java 17 from Kafka 4.0 onward, and clients need at least Java 11. A VM estate that has run older JVMs or an older Kafka release can hide these gaps until the new container images are built. Check the Kafka release on the source cluster, the release of the Strimzi operator and the Kafka version it deploys, and whether the upgrade path to a supported release is a single step. Confirm that every client runtime meets the Java floor before cutover.
Storage class and disk performance surprises
Kubernetes persistent volumes may use a different disk type, filesystem, or replication layer than the bare-metal or VM disks the brokers used. Throughput, fsync latency and IOPS can drop once volumes are network-attached, which shows up as consumer lag under peak load rather than during tests. Benchmark the chosen storage class with a produce and consume workload that matches your largest topics, and confirm reclaim policy and volume expansion behavior with your platform team before any data is copied.
Rollback plans that expire too early
The rollback window closes as soon as producers write to Strimzi or as soon as data stops flowing back to the VM cluster. Teams often delete VM brokers once MirrorMaker 2 reports caught-up lag, which removes the only fallback path. Write the rollback criteria before cutover, keep the VM cluster running and replicating in reverse until the agreed observation period ends, and confirm with your change board how long that period must be. Test the reverse switch in a rehearsal, not for the first time during an incident.
Questions teams ask before moving Kafka to Kubernetes
How much does a Kafka move from virtual machines to Kubernetes cost?
No supplied figure sets this cost, and the total depends on scope. The main cost components are the people doing the design, build, data movement and client cutover, plus the Kubernetes platform itself if it does not exist yet. Strimzi and Apache Kafka are open source under the Apache License 2.0, so software licensing is usually not the cost driver. Spend rises with the number of clusters, topics, users and client applications to switch, the depth of security integration, and how many regions must be replicated. One-time work covers the initial build and migration; recurring work covers upgrades, patching and on-call support. Ask any partner for a written, fixed-scope quote that lists each phase, the environments included, and the assumptions behind it.
How long does a VM to Kubernetes Kafka migration take?
Duration depends on the factors that set the work, not on a fixed figure. The main drivers are the number of topics and partitions, the total data volume that must be copied with MirrorMaker 2, the number of consumer groups and producers to switch, and how many security mappings must be rebuilt as custom resources. Clusters with strict change windows, many dependent teams or unfinished platform foundations usually take longer. Cutover approach also matters: a planned switch with a replicated standby is different from a rushed one. Ask for a schedule that ties each phase to an entry and exit check, and confirm which phases depend on your platform team's readiness.
What does the internal team need to provide for this migration?
The internal team provides knowledge of the current cluster and decision rights. Expect to supply:
- Inventory of brokers, controllers, topics, partition counts, retention settings, ACLs and SCRAM or other credentials in use
- Named owners for each producer and consumer application, plus change windows and rollback criteria
- A working Kubernetes platform with storage classes, network policy, secrets handling and access for the Strimzi operator
- Access to the target environment and to the source cluster for replication
The platform team will also need to agree on how Kafka users map to Kubernetes resources and who reviews the resulting manifests.
Can our own team run this migration with the documented tools?
Yes, a capable team can use the documented tools, since Strimzi manages Kafka on Kubernetes and MirrorMaker 2 is built on Kafka Connect and replicates topics, consumer group offsets and ACLs between clusters. The harder parts are the design decisions: node pool layout, listener and authentication design, authorization policy, and a tested cutover plan. Confirm internally that you have engineers familiar with Kafka operations, Kubernetes operators and TLS, and that someone can own the work after go-live. A partner can fill gaps in that experience, or run the migration under a fixed-scope agreement with written deliverables.
What happens to consumer offsets during cutover?
MirrorMaker 2 replicates consumer group offsets from the source cluster to the target, so consumers can resume near where they stopped. The offsets are only as current as the last replication cycle, which means consumers can see some reprocessing if they switch before replication catches up. Plan the cutover so that consumers stop on the source, the final offsets are synchronized, and each consumer group is verified on the target before it starts. Test this on a non-production copy first. Confirm the exact offset translation behavior and any lag in your MirrorMaker 2 version against the geo-replication documentation.
How do we keep our existing Kafka security during the move?
Map each current control to its Kubernetes equivalent before cutover. Kafka authenticates clients with SSL or SASL, with mechanisms such as SCRAM-SHA-512 or OAUTHBEARER, and authorization in KRaft clusters is stored in the metadata log through the StandardAuthorizer. Rebuild users, ACLs and certificates as Strimzi custom resources, and keep the default-deny behavior for resources without ACLs. Kubernetes stores Secrets unencrypted in etcd by default, so confirm encryption at rest and least-privilege RBAC before copying any credential material. Test access for each client identity on the target before switching traffic.
Who keeps the cluster running after the migration?
After go-live, your team owns the cluster unless a support agreement says otherwise. Ongoing work includes Kafka and Strimzi upgrades, Kubernetes version upgrades, certificate rotation, backups and restore tests, monitoring and capacity changes. The Kafka project publishes a time-based release plan and supports rolling upgrades from the last three releases to the latest, so plan upgrade windows around that. Support can be provided as a retainer, which is ongoing and recurs, or handed over through a runbook. Ask any provider to define in writing who responds to incidents and how upgrades are scheduled.
Which compliance evidence changes when Kafka moves to Kubernetes?
The control objectives stay the same, but the evidence changes because access, configuration and logs now come from Kubernetes resources and the platform around them. Auditors will want to see how cluster configuration is versioned, who can change Strimzi custom resources, how secrets are stored and rotated, and how access logs are retained. Confirm with your assessor which controls they expect to test and which artifacts they will request. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors and certification bodies issue any audit report or certification.
How DeployOpen works on this
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For a move from virtual machines to Strimzi, that means scoping the cutover against your current cluster, building the Kubernetes target in your environment, and handing over a cluster your team can operate.
How we scope
- Inventory current brokers, controllers, topics, ACLs, users and client applications before any target design is agreed
- Agree in writing which topics, consumer groups and clients move in each wave and which stay on the VMs
- Confirm the target Kubernetes distribution, Strimzi version, storage classes and network paths with your platform team
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts
How we build
- Build KRaft node pools for controllers and brokers in a non-production namespace first, matching partition and retention settings
- Recreate topics and users as Strimzi custom resources from version-controlled manifests, not manual changes
- Configure MirrorMaker 2 replication, then test offset translation, ACL replication and lag before any client switch
- Run failover rehearsals for each client group and record the results against the agreed acceptance criteria
How we hand over
- Deliver the manifests, runbooks, cutover plan, rollback steps and access model in your own repository
- Walk your operators through node pool changes, topic and user provisioning, and MirrorMaker 2 monitoring
- Document which controls your team owns and which evidence your auditors will need from the new platform
- Confirm the decommissioning steps for the VM cluster, including data retention and final backup checks
How we support
- Support after cutover is available as a retainer covering upgrades, patching and incident assistance
- Retainers can include planned Kafka and Strimzi upgrades, reviewed against the upgrade notes for each release
- Continuous security testing of the cluster and its client endpoints can be scoped alongside operations
- Ask any provider to confirm the support hours, response terms and included upgrade work in the written quote
