Migration path · MassTransit
Introduce MyServiceBus at a service boundary, not as a blind package swap.
The safest path is incremental: keep the existing MassTransit services running, introduce one MyServiceBus C# or Java participant through the verified common wire subset, and move ownership only after its contracts and operational behavior pass.
MyServiceBus interoperability evidence is pinned to MassTransit 8.5.1. API familiarity helps developers, but it is not source compatibility and it is not a promise that future commercial MassTransit releases will retain the same wire behavior.
API migration map
| Intent | MassTransit | MyServiceBus C# | Migration note |
|---|---|---|---|
| Publish an event | IPublishEndpoint.Publish | IPublishEndpoint.Publish | Preserve publish intent and validate the selected wire profile. |
| Send a command | ISendEndpoint.Send | ISendEndpoint.Send | Preserve the destination and endpoint-name convention. |
| Consume | IConsumer<T>.Consume | IConsumer<T>.Consume | Port registration and middleware deliberately; matching names do not make assemblies interchangeable. |
| Request/response | IRequestClient<T>.GetResponse | IRequestClient<T>.GetResponseAsync | Re-test response, fault, timeout, and temporary endpoint behavior. |
| Transactional outbox | Bus/Consumer Outbox providers | PostgreSQL Bus Outbox MVP | Do not point both products at the same outbox tables. |
| Scheduling | Transport or persistent scheduler | Volatile provider, PostgreSQL outbox delay, or custom message-aware provider | Outbox delayed intent is durable; broker-native, Quartz, recurring, and persisted-cancellation adapters remain future work. |
1. Inventory the behavior you actually use
Record contracts, message URNs, serialization, endpoint names, routing, headers, request timeouts, retry and terminal-failure policy, scheduled work, outbox ownership, observers, and broker-specific configuration. Mark every feature outside the verified interoperability matrix before changing a service.
2. Add a side-by-side participant
A Java service is often the lowest-risk first step because it extends the estate without replacing a working .NET service. Give it its own receive endpoint, publish and consume shared contracts through the MassTransit compatibility profile, and run live broker tests in both directions. The same approach works for a new C# service.
3. Move one owned boundary at a time
- Move the consumer and its endpoint as one deployment boundary.
- Keep one active owner for a queue unless competing consumption is intentional.
- Assert message identity, correlation, faults, retries, error/skipped preservation, and shutdown behavior.
- Retain MassTransit where sagas, routing slips, durable scheduling, or another unmatched feature is required.
- Use the broker's observable state and application outcomes as migration evidence—not API resemblance alone.
4. Treat outbox data as an ownership handoff
MyServiceBus has its own normalized C# ↔ Java PostgreSQL schema. It does not read or write MassTransit outbox tables. Stop the old writer, drain or deliberately account for its pending records, deploy the MyServiceBus schema under a distinct service partition, and only then transfer production writes. Never have both implementations assume ownership of the same persisted outbox records.
5. Promote only the capabilities you proved
The current project is pre-1.0. Use the API and readiness matrix to separate verified preview behavior from MVP and experimental work. A successful first service is evidence for that service and transport profile—not an automatic approval for every MassTransit workload.