Migrating a data privacy platform from GCP to AWS

Executive Summary

The client operates a data privacy platform that lets enterprises tokenize, store, and protect sensitive data. Delivered as SaaS, its customer base is concentrated on AWS — but the platform itself ran on Red Hat OpenShift on Google Cloud, with a stateful data tier and a GPU-backed machine learning tokenization service at its core.

Fission Labs was engaged to move the platform to Red Hat OpenShift Service on AWS (ROSA) over a 13-week delivery window, followed by a two-week hyper-care stabilization period. The team’s first approach — a standard backup-and-restore migration — recovered the platform’s stateless services cleanly but could not bring the stateful data tier into service, because cross-cloud storage identity cannot be carried between providers. That finding redirected the engagement to a declarative rebuild: the platform was reconstructed from clean, cloud-neutral definitions, with data moved at the database tier rather than the volume tier. The result was a fully functional platform on AWS with verified data integrity and no regression in the ML service.

What this case study covers

• The business pressure that made a same-cloud migration insufficient and AWS the required target.
• The technical constraints that ruled out a straightforward backup-and-restore, and the rebuild approach that replaced it.
• The AWS services the rebuilt platform runs on and the measurable outcome for the client.

Business Challenge

The client’s growth was increasingly tied to enterprise customers who standardize their own infrastructure on AWS. Selling and delivering a privacy platform that lived on a different cloud created friction in every enterprise sales cycle — procurement, security review, and data-residency conversations all became harder to close when the platform itself sat outside the customer’s own cloud boundary. Moving the platform natively onto AWS was a commercial necessity, not an infrastructure preference.

The platform, however, was not a simple set of stateless web services. It carried:

• ‍A stateful data tier — databases, a message broker, and a cache, all managed by Kubernetes operators — where the correctness of every record mattered and no data could be lost in transit.‍
• A GPU-backed ML tokenization service at the core of the product, which had to be re-hosted without any loss of accuracy or throughput.‍
• No existing playbook for moving a stateful OpenShift platform between cloud providers — this was new ground for the team and, more importantly, for the industry pattern being followed.

WHY THIS WAS HARD - The team’s first, most standard approach — back up the cluster and restore it on the new cloud — recovered every stateless service cleanly. The stateful services did not come back. Storage in Kubernetes is bound to the cloud that provisioned it: identifiers, zones, and provisioner references travel with a restored object, and no equivalent exists on a different cloud. Correcting those references after the fact required deleting and recreating the very objects the restore existed to preserve — which meant the data would be lost regardless. That finding, reached early, is what shaped the solution that followed.

Technical Solution

Rather than replay a snapshot of the GCP cluster onto AWS, Fission Labs rebuilt the platform on AWS from its own declarative definitions and moved data at the one tier where it is genuinely portable across clouds: the database.

Provision a clean AWS target

A Red Hat OpenShift Service on AWS (ROSA) cluster with a hosted control plane was stood up with AWS-native networking, identity, and storage from the outset — no inherited cloud-specific configuration.

Normalise and carry the artifacts

Deployment manifests, configuration, and secrets were exported from the source cluster and stripped of every GCP-specific reference — server-populated fields, storage class names, and provisioner annotations — before being re-applied on AWS. Container images were transferred to Amazon ECR with digest parity preserved, so every running workload on AWS was verified to match its source image exactly.

Rebuild the stateful tier first, then restore data

The database, messaging, and cache layers were stood up on AWS-native storage and proven healthy before any data was loaded. The databases were then restored from a logical, schema-and-rows export—a cloud-neutral artifact with no embedded cloud identity — and verified row-for-row and checksum-for-checksum against the source before the application layer was allowed to start.

Deploy the application tier, gated on health

With the data tier verified, application services were brought up namespace by namespace, each gated on the previous one’s rollout status and a functional check before the next was started — so no service ever came online against a data layer that wasn’t ready.

Right-size the GPU tier for the ML service

The tokenization service was first placed on a standard GPU instance sized for the workload on paper. In practice, model weights plus inference headroom exceeded the memory available on that instance, and the service could not start reliably. The team moved it to a GPU instance class with double the memory, which resolved the issue immediately and left headroom for future growth in model size or batch volume.

VALIDATION - Before cutover, the rebuilt platform was checked end to end: every storage volume was bound and healthy on AWS-native storage, every database was verified against the source by row count and checksum, every container image was confirmed against its source digest, and a full functional pass was made across the product — including the tokenization path that exercises the GPU service — before traffic was moved.

Key AWS Services Used

The rebuilt platform runs natively on AWS, using managed services in place of the self-managed and GCP-native components it previously depended on.

• ‍Red Hat OpenShift Service on AWS (ROSA) - Managed OpenShift control plane and compute for the platform’s containerised services‍
• Amazon EKS - Kubernetes-based compute supporting workloads alongside the ROSA environment‍
• Amazon ECR - Private container registry for all service images, replacing the source cloud’s registry‍
• Amazon S3 - Object storage for backups, logical database exports, and application data‍
• Amazon Bedrock - Managed foundation-model access supporting the platform’s AI-driven capabilities‍
• AWS Secrets Manager - Centralised storage and rotation for application credentials, replacing in-cluster-only secrets‍
• AWS KMS - Encryption key management for data at rest across storage and secrets‍
• Amazon CloudWatch - Monitoring, logging and alerting for the migrated platform‍
• AWS DataSync - Bulk data transfer support during the migration window

Project Outcome and Impact

The migration was completed within the planned delivery window, followed by a two-week hyper-care period to confirm stability under real production load before Fission Labs stepped back from active monitoring.

• ‍Zero data loss. Every database was verified row-for-row and checksum-for-checksum against the source before cutover.‍
• Full workload parity. Every stateless, stateful, and GPU-backed service was migrated and validated — including the tokenization service, which showed no regression in accuracy or throughput after the GPU instance change.‍
• No unplanned downtime at cutover. The gated, tier-by-tier rollout meant the application layer was only started once the data layer was already verified healthy.‍
• A reusable migration pattern. Every artifact in the new environment exists as a version-controlled, cloud-neutral definition — turning the client’s next environment build into a deployment rather than a migration.

Business impact

With the platform now running natively on AWS, the client removed a recurring point of friction from its enterprise sales motion: prospects and customers already standardized on AWS no longer need to evaluate a cross-cloud dependency during procurement or security review. The platform is positioned to scale directly alongside its customer base’s own AWS footprint.

Conclusion

The client’s migration is a case study in a pattern that comes up often in cross-cloud work: the obvious approach — back up and restore — is also the one most likely to fail silently for stateful workloads, because cloud-provisioned storage does not travel between providers. Recognizing that early, rather than after a partial restore was declared “done,” is what kept the engagement on schedule and the data intact.

By rebuilding the platform from clean, cloud-neutral definitions and moving data at the tier where it is actually portable, Fission Labs delivered a the client platform that is not just running on AWS but built in a way the client can repeat for every environment that follows — with the same confidence in data integrity and service continuity that this migration proved out.

ENGAGEMENT SNAPSHOT - Practice: DevOps  ·  Industry: HiTech  ·  Target architecture: Red Hat OpenShift Service on AWS (ROSA HCP)