Introduction

A Kafka platform migration can move Schema Registry to a new endpoint while Kafka Connect workers still serialize records against the old one. Connect jobs keep running, but new schemas never appear in the intended registry, one connector writes successfully while another fails after the old registry is removed, or data lands with incompatible subject history because worker config, connector overrides, and injected secrets often change in different places.

Treat this as a serialization-path problem instead of a generic Kafka outage. Start by checking which Schema Registry URL an affected connector task actually uses at runtime, because migrations often validate the new registry from an admin workstation while distributed workers continue using older converter settings.

Symptoms

  • Apache Kafka Connect still writes to the old Schema Registry after migration
  • Connector tasks run, but schemas register only in the retired registry
  • One connector uses the new registry while another still targets the previous endpoint
  • Serialization failures start only after the old registry is restricted or shut down
  • Brokers and topics are healthy, but migrated connectors never use the new schema service
  • The issue started after moving Schema Registry, Kafka Connect, or platform configuration management

Common Causes

  • Worker-level key or value converter settings still reference the old Schema Registry URL
  • A connector override keeps using the previous registry even though the cluster default changed
  • Secret injection, environment variables, or mounted properties files keep restoring the retired endpoint
  • One worker group or Connect cluster was updated while another still runs older config
  • TLS trust, authentication, or mTLS settings were migrated for the new registry, but the actual URL was not
  • Validation confirmed the new registry was reachable but did not verify which endpoint live connector tasks actually used

Step-by-Step Fix

  1. Capture one affected connector task and record the worker group, converter settings, Schema Registry URL, and authentication method it actually uses, because the live serialization path determines where schemas are really registered.
  2. Compare that active registry path with the intended post-migration platform design, because one stale converter setting can keep whole connector fleets tied to the retired service.
  3. Review worker properties, connector configs, distributed config providers, Kubernetes manifests, and secret-injection paths for references to the old Schema Registry, because Kafka Connect serialization behavior can come from both shared worker defaults and per-connector overrides.
  4. Check key and value converter settings separately for each affected connector, because one side can be updated while the other still serializes through the previous registry.
  5. Update the authoritative converter configuration and secret source so affected workers and connectors use the intended registry endpoint, because standing up the new Schema Registry alone does not retarget existing Connect tasks.
  6. Restart or roll the affected workers only as needed and run a controlled connector write, because a healthy worker process does not prove the right registry handled serialization.
  7. Confirm the intended registry receives new subject registrations or compatibility checks from the migrated connector, because successful data flow can still hide schema operations against the old service.
  8. Verify the old registry no longer receives schema writes, reads, or compatibility requests from affected workers, because split schema ownership can remain hidden while both endpoints stay reachable.
  9. Document which team owns worker defaults, connector overrides, and secret delivery so future platform cutovers verify the actual runtime Schema Registry target before retiring the previous endpoint.