Migrating from Legacy Tokenization and Encryption Platforms

Overview

Customers adopt Ubiq in several migration contexts. Some are replacing a legacy tokenization, encryption, masking, or data protection platform such as Voltage, Thales, Protegrity, or similar systems. Others are modernizing applications, moving data between environments, consolidating data protection tools, or introducing identity-aware protection as part of a broader architecture change.

These migrations do not need to be disruptive big-bang projects. Depending on the current platform, protected data format, decrypt/detokenize capability, application architecture, and target Ubiq deployment model, customers can use phased, wrapper-based, bulk, forward-only, or hybrid migration approaches.

This document explains common migration scenarios, practical migration patterns, and the information needed to scope a migration from a legacy data protection platform to Ubiq.

Common Migration Contexts

Customers may migrate to Ubiq for several reasons. The migration path depends on the starting point, the customer’s desired end state, and whether existing protected data needs to be converted immediately or can transition over time.

Legacy platform replacement

A customer may be replacing an existing tokenization, encryption, masking, or data protection platform such as Voltage, Thales, Protegrity, or a similar legacy system.

In this scenario, the customer may already have protected data in production, existing field-level protection rules, legacy key-management processes, application integrations, and operational workflows that depend on the current platform.

The migration goal is usually to move protection and access enforcement to Ubiq while minimizing disruption to applications, databases, users, and downstream systems.

Application or infrastructure modernization

A customer may be modernizing an application, database, API layer, data pipeline, or infrastructure environment and may want to introduce Ubiq during that transition.

Examples include:

Moving from legacy applications to modern services
Moving from on-premises infrastructure to cloud or hybrid environments
Replatforming databases or warehouses
Introducing new API or gateway patterns
Updating application-level data protection logic
Consolidating older encryption or tokenization controls

In these cases, migration to Ubiq may happen as part of a broader architecture change rather than as a standalone replacement project.

Data platform migration

A customer may be moving data between databases, warehouses, object stores, analytics platforms, or pipeline environments.

In this scenario, the customer may choose to decrypt, detokenize, reprotect, or transform protected data as part of the migration process. Ubiq can support these workflows through libraries and integrations that protect and unprotect data according to the customer’s dataset definitions, configuration, and access permissions.

Policy and access model modernization

A customer may be moving from static application-level controls or legacy key-based access models to Ubiq’s identity-aware protection model.

In this scenario, the migration is not only about changing how data is encrypted, tokenized, or masked. It is also about defining which identities, applications, services, users, or workflows should be able to protect or unprotect specific datasets.

This may involve mapping legacy access rules into Ubiq dataset definitions, configuration, and access permissions.

Gradual coexistence

A customer may run a legacy data protection platform and Ubiq side by side during a transition period.

This can be useful when the customer wants to avoid a big-bang migration, maintain application continuity, and allow protected data to move to Ubiq over time as it is accessed, updated, or rewritten.

Migration Does Not Have to Be Big-Bang

A big-bang migration is possible. In a big-bang migration, the customer decrypts or detokenizes legacy protected values, reprotects them with Ubiq, validates the output, and cuts over applications or workflows to Ubiq within a defined migration window.

However, big-bang migration is not the only option.

Many customers can use a more controlled migration model where the legacy platform continues to decrypt or detokenize existing protected values while Ubiq protects new or reprotected values going forward. This allows the customer to migrate over time instead of reprocessing every historical value upfront.

This can reduce operational risk because:

Existing applications can continue reading legacy protected values during the transition.
New or updated values can be protected with Ubiq going forward.
Migration can occur gradually as data is accessed, updated, or passed through controlled workflows.
Customers can validate field behavior, application behavior, and downstream system compatibility incrementally.
Customers can avoid unnecessary reprocessing of historical data that may not need immediate conversion.

In some cases, legacy platforms may allow customers to maintain decrypt/detokenize capability after broader license expiration or during a transition period. When available, this can make phased migration cleaner because the legacy platform can continue to unprotect existing values while Ubiq becomes the protection model for new and reprotected data.

Migration Approaches

Ubiq can support several migration approaches. The best approach depends on the customer’s current platform, protected data format, decrypt/detokenize capability, application architecture, key-management requirements, and desired end state.

Phased Migration

In a phased migration, the customer transitions from a legacy platform to Ubiq over time.

The customer sets up the relevant dataset definitions, configuration, and access permissions in Ubiq. Existing protected values remain in their legacy format until they are accessed, updated, rewritten, or processed through a migration workflow.

As values are reprotected, they are protected with Ubiq going forward.

This approach is useful when:

The customer wants to avoid a disruptive big-bang cutover.
Existing protected values can remain in place during the transition.
The legacy platform can still decrypt or detokenize existing values.
Applications can be updated incrementally.
The customer wants to validate behavior over time before full cutover.

A phased migration can be especially useful in large environments where protected data is spread across multiple systems, applications, databases, or workflows.

Wrapper-Based Migration

A wrapper-based migration uses a migration wrapper, crypto abstraction layer, or dual-provider integration layer to route protect and unprotect operations to the appropriate provider during the transition.

The wrapper can support both the legacy platform and Ubiq at the same time.

For existing protected values, the wrapper can call the legacy platform to decrypt or detokenize the value. When the value is written back, updated, or reprotected, the wrapper can protect it with Ubiq. Over time, more protected data naturally transitions from the legacy platform to Ubiq.

For new data, the wrapper can route protect operations directly to Ubiq.

The wrapper may use routing logic such as:

Value format
Prefixes or markers
Field or dataset mapping
Metadata
Versioning
Application context
Migration state
Source system or destination system
Metadata columns
Provider prefixes
Known exclusion characters or patterns

The goal is to allow the customer to operate both providers during a controlled transition period without requiring every protected value to be converted upfront.

Example wrapper-based flow

A typical wrapper-based migration may work as follows:

An application reads a protected value.
The wrapper determines whether the value is protected by the legacy platform or by Ubiq.
If the value is in the legacy format, the wrapper calls the legacy platform to decrypt or detokenize it.
The application uses the clear value according to its normal workflow.
When the value is written back, updated, or reprotected, the wrapper calls Ubiq to protect it.
The newly protected value is stored in the Ubiq format going forward.
Over time, values naturally transition from the legacy platform to Ubiq as they are accessed or updated.

This approach can provide a cleaner migration path because the customer can migrate active data first while allowing less frequently used historical data to transition later or remain unchanged until needed.

Identifying Legacy and Ubiq-Protected Values

In phased or wrapper-based migrations, the workflow needs a reliable way to determine whether a protected value should be handled by the legacy platform or by Ubiq.

This routing decision is an important part of migration design. The approach depends on the legacy format, the Ubiq protection format, the field being protected, and whether the customer can safely add metadata or markers during the transition.

Common approaches include:

Using a metadata column that indicates whether the value is legacy-protected or Ubiq-protected
Adding a prefix or marker to newly Ubiq-protected values
Using a dataset configuration that produces an identifiable character or pattern that does not appear in the existing legacy data

The best approach should be selected during migration design. In some cases, the legacy and Ubiq formats may be easy to distinguish. In other cases, the customer may need to add explicit metadata, prefixes, or routing rules to avoid ambiguity.

The goal is to make the migration wrapper deterministic: for each protected value, the workflow should know which provider should be used to unprotect the value and which provider should be used to protect it going forward.

Bulk Decrypt and Reprotect

In a bulk decrypt and reprotect migration, the customer retrieves protected data from its own systems, uses the legacy platform to decrypt or detokenize existing values, and then uses Ubiq to protect those values before writing them back to the original system or to a new customer-controlled destination.

This approach is useful when:

The customer wants a faster cutover.
The customer wants to convert a defined data set within a specific migration window.
The customer has a clear inventory of protected fields and source systems.
The customer can access legacy decrypt/detokenize capability.
The customer can validate output before completing cutover.

Bulk migration should be treated as a planned data migration process. Customers should plan for batching, retries, error handling, access logging, validation, rollback, and downstream application testing.

For large datasets, customers may choose to write Ubiq-protected output to a separate migration location first. This allows validation before modifying the original source system or completing cutover.

Forward-Only Migration

In a forward-only migration, the customer leaves legacy protected values in place and uses Ubiq only for new data or new workflows going forward.

This approach is useful when:

Historical data does not need to be converted immediately.
The customer is launching a new application, database, pipeline, or workflow.
The customer wants to minimize migration complexity.
Legacy protected data can remain available through the legacy platform for as long as needed.
The business value is focused on new data protection and new access enforcement.

Forward-only migration can be an effective starting point when a customer wants to adopt Ubiq quickly while deferring historical conversion.

Hybrid Migration

A hybrid migration combines multiple approaches.

For example, a customer may:

Use Ubiq for all new data going forward.
Use a wrapper for high-traffic application paths.
Bulk migrate selected high-value datasets.
Leave low-use historical data in legacy format until it is accessed.
Migrate different business units, applications, or regions in phases.

Hybrid migration is often appropriate for large enterprise environments where different systems have different risk profiles, timelines, owners, and operational requirements.

What Needs to Be Mapped

A migration from a legacy platform to Ubiq is usually a normal scoping exercise. The key is to understand the existing protection model and the desired Ubiq end state.

Important items to map include:

Legacy platform in use
Protected data fields
Legacy protected formats
Whether the customer can still decrypt or detokenize legacy protected values
Dataset definitions, configuration, and access permissions needed in Ubiq
Identity and access requirements
Key-management requirements
Application or workflow integration points
Source systems and destination systems
Search, analytics, or downstream processing requirements
Migration timeline and cutover preference
Validation and rollback requirements

These are normal migration scoping items. They are not unusual blockers, and they do not necessarily imply a heavy migration effort.

Dataset Definitions, Configuration, and Access Permissions

Ubiq uses dataset definitions, configuration, and access permissions to define how protected data should be handled.

During migration, legacy field-level protection rules need to be mapped into Ubiq’s model. This may include:

Which fields or data elements are protected
Which protection technique is required
Whether the output format needs to preserve length or structure
Whether the protected value needs to support search or matching
Which identities or workflows can protect data
Which identities or workflows can unprotect data
Which applications, databases, APIs, pipelines, or integrations are in scope

The migration does not require Ubiq to reproduce every internal object or policy structure from the legacy platform. Instead, the goal is to recreate the required protection behavior and access model in Ubiq.

Identity and Access Model

Migration is also an opportunity to modernize how access to sensitive data is controlled.

Legacy platforms may be tied to application-level access, static credentials, local configuration, or platform-specific policy models. Ubiq can enforce access based on identities, access groups, dataset definitions, configuration, and access permissions.

Identities may represent:

Users
Applications
Services
APIs
Jobs
Pipelines
Other machine or non-human actors

During migration, customers should define which identities need to protect or unprotect which datasets. This allows Ubiq to enforce access behavior going forward instead of simply recreating legacy protection mechanics.

Key Management Considerations

Legacy platforms may use different key-management models, including vendor-managed keys, customer-managed keys, HSM-backed keys, or platform-specific key hierarchies.

During migration, customers should identify:

Where legacy keys are managed
Whether legacy decrypt/detokenize capability is still available
Whether customer-managed keys are required
Whether HSM-backed control is required
Whether key rotation or re-keying is part of the migration
Whether the customer has regulatory or internal key-custody requirements

Ubiq supports customer-controlled key-management options, including Customer Managed Key / BYOK and Bring Your Own HSM / BYOHSM, for customers with stricter key-control, custody, continuity, or recovery requirements.

Key-management requirements should be scoped during technical design because they may affect the migration approach, deployment model, and validation plan.

Compatibility and Vendor-Specific Considerations

Legacy tokenization and encryption platforms often use proprietary formats, tokenization rules, key models, metadata, and policy structures.

Because of that, Ubiq should not be assumed to automatically import another vendor’s entire configuration and reproduce it without scoping. The right migration path depends on the customer’s existing platform, available decrypt/detokenize capability, protected data formats, and desired Ubiq end state.

This does not mean migration needs to be heavy or disruptive. It means the migration should be scoped using normal technical discovery:

What platform is currently protecting the data?
What fields are protected?
What formats are used?
Can the customer decrypt or detokenize existing protected values?
What should Ubiq protect going forward?
What access model should Ubiq enforce?
What systems need to be updated or integrated?

Once those questions are answered, customers can usually choose from several practical migration paths.

Validation and Cutover

Migration should include a clear validation and cutover plan.

Validation may include:

Field-level testing
Format validation
Record count comparison
Sample value comparison
Application behavior testing
Search or matching behavior testing
Downstream reporting or analytics testing
Performance testing
Error handling and retry testing
Rollback testing

Cutover may be phased by:

Application
Dataset
Field
Business unit
Environment
Region
Workflow
Data domain

Customers should avoid treating migration as a single all-or-nothing event unless a big-bang approach is explicitly desired and operationally appropriate.

Recommended Migration Practices

For migrations from legacy tokenization or encryption platforms, Ubiq recommends:

Start by identifying the migration context and desired end state.
Inventory protected fields, formats, applications, databases, and workflows.
Confirm whether legacy decrypt/detokenize capability remains available.
Decide whether migration should be phased, wrapper-based, bulk, forward-only, or hybrid.
Map legacy protection requirements into Ubiq dataset definitions, configuration, and access permissions.
Define the identity and access model Ubiq should enforce going forward.
Confirm key-management requirements early.
Validate with representative data before full production rollout.
Use batching, retries, logging, and rollback planning for bulk migration workflows.
Consider wrapper-based migration when the customer wants to avoid a disruptive cutover.
Use phased cutover where different applications, datasets, or workflows have different timelines.

Key Takeaways

Migrating from a legacy tokenization, encryption, masking, or data protection platform to Ubiq does not have to require a disruptive big-bang conversion.

Customers can use phased, wrapper-based, bulk, forward-only, or hybrid migration approaches depending on their current platform, decrypt/detokenize capability, protected data formats, and desired end state.

A wrapper-based migration can allow the legacy platform and Ubiq to coexist during a transition period, with legacy values decrypted or detokenized by the legacy platform and new or reprotected values protected by Ubiq going forward.

Ubiq does not need to automatically import every proprietary vendor configuration to support a successful migration. The practical goal is to map the customer’s existing protection requirements into Ubiq dataset definitions, configuration, and access permissions, then choose the migration approach that best fits the customer’s environment and timeline.