# Backwards Compatibility

<!-- Version variant: asbs_4; default: [/transports/azure-service-bus/compatibility.md](/transports/azure-service-bus/compatibility.md) -->


The Azure Service Bus transport is backward compatible with the legacy Azure Service Bus transport under certain conditions.

## Conditions

### Forwarding topology

The Azure Service Bus transport only supports the [forwarding topology](/transports/azure-service-bus/topology.md).

### Single namespace

The Azure Service Bus transport only supports a single namespace.

### Topic path must match

Both transports must use the same topic path for publishing to work correctly. The Azure Service Bus transport must use the same topic as the old transport. Also, only one topic path is allowed.

Therefore, for publishers that are using the legacy transport version 7 or lower, the number of entities in a bundle must be restricted to one using:

```csharp
forwardingTopology.NumberOfEntitiesInBundle(1);
```

### Namespace alias is not used

The Azure Service Bus transport doesn't support namespace aliases.

### Sanitization rules must be aligned

If the legacy transport [sanitizes](/transports/azure-service-bus/configuration.md#entity-creation) entity names, the sanitization logic must be updated to be compatible with the new transport.

For example, for the `ValidateAndHashIfNeeded` strategy, the sanitization functions must include the strategy logic to preserve the same entity names.

<!-- snippet: asb-sanitization-compatibility -->

```cs
string HashName(string input)
{
    var inputBytes = Encoding.Default.GetBytes(input);
    // use MD5 hash to get a 16-byte hash of the string
    var hashBytes = MD5.HashData(inputBytes);

    return new Guid(hashBytes).ToString();
}

const int MaxEntityName = 50;

transport.SubscriptionNamingConvention = n => n.Length > MaxEntityName ? HashName(n) : n;
transport.SubscriptionRuleNamingConvention = n => n.FullName.Length > MaxEntityName ? HashName(n.FullName) : n.FullName;
```

<!-- endsnippet -->