Entity change restrictions during migration

The entity change restrictions described in this chapter start at the Dual Version deployment and provisioning stage, from the moment the source system database is copied to the target system. For product catalog entities, these restrictions result in a product catalog freeze.

Entities such as products, bundles, and subscriptions are copied from the source to the target system once, as part of the database copy (before customer batches are transferred) and are not synchronized automatically after that. If you change these entities on either system after the database is copied, the two systems will be out of sync by the time a customer is transferred. This inconsistency may cause the customer transfer to fail or services to behave incorrectly on the target system after the transfer or on the source system if the customer needs to be transferred back.

For example, if you add a new messaging service to a product on the source system after the database has been copied, that product will not include the messaging service on the target system. You can't fix this by manually creating and adding the same service to the product on the target system as it would be assigned a different internal ID there. As a result, the system can't recognise it as the same service that exists on the source system, and any usage already recorded on the source cannot be linked to it. For other kinds of changes, manually replicating them on the target system is possible,  but there's no guarantee that this will keep the two systems truly in sync, since settings may be named or organized differently between releases. If this causes a customer transfer failure or any other issues, your team and PortaOne Support will need to investigate the issue, identify the mismatch, and determine how to resolve it. This can delay the overall Dual Version migration and require additional effort from both teams.

To reduce the risk of customer transfer failures and migration delays caused by inconsistencies between the source and target systems, plan product catalog changes around the product catalog freeze:

• Configure the products you plan to use during migration on the source system before the product catalog freeze, or
• If you need new products during the product catalog freeze, create them on the target system. New customers can use them right away. Customers transferred from the source system can also switch to these products (however, note that once a customer’s account is assigned to one of these new products, that customer can no longer be transferred back to the source system, since there's no matching product there).

The exact restrictions depend on the entity type – see the table.

For Dual Version jumps from older releases, restrictions are enforced procedurally rather than by the system. The system does not technically block prohibited changes, so administrators must follow the restrictions described in this chapter. For newer releases, the system blocks prohibited changes automatically.

• For jumps MR70–MR85: Change restrictions are procedural: the system does not block prohibited changes in the web interface or via the API.
  Make sure your team is aware of the restrictions and follows them during the whole migration process.
• For jumps MR85–MR100: On the source system, prohibited changes are not blocked by default, but blocking can be enabled via the Configuration server web interface. On the target system, prohibited changes are blocked by default.
• For jumps from MR100: Prohibited changes are blocked by default on both systems, in both the web interface and the API.
  If your system has multiple billing environments and some of them have already been fully migrated to the target system while others are still in progress, PortaOne Support can disable change blocking for the fully migrated environments.

The table below shows what changes are allowed/restricted for each entity on the source and target systems during Dual Version migration.

Some entities are automatically synchronized between the source and target systems. For details, see Automatic entity synchronization during Dual Version migration.

• ✅ – allowed
• ✅ apply to target/source too – allowed, but the same change must also be made on the other system to keep it in sync
• ✅ newly added only – allowed only for entities created after the database has been copied; existing (already-copied) entities can't be changed
• 🚫 – restricted