D3V turned a single-cloud, multi-tenant energy software platform into one that runs on AWS or Google Cloud from the same codebase, with full feature parity and no disruption to live customers.
At a glance
| Client | A leading enterprise energy software provider serving major utilities with a multi-tenant Commercial & Industrial (C&I) application suite |
|---|---|
| Industry | Energy technology / utilities software |
| Challenge | Extend a decade-old, AWS-only platform to Google Cloud without customer downtime, SLA breaches, or a second codebase to maintain |
| Solution | Seven infrastructure layers mapped to managed Google Cloud services; applications in Java, Python, Ruby and PHP refactored to run on either cloud |
| Outcome | Feature parity on Google Cloud, zero operational disruption, and a modernized security and runtime baseline |
| Google Cloud services | Compute Engine, Cloud SQL, Cloud Storage, Memorystore, Cloud CDN, Pub/Sub, Cloud Functions, Secret Manager |
The challenge
The client needed to offer its platform on Google Cloud as well as AWS, so it could meet utility customers’ hosting preferences and reduce vendor lock-in. The platform delivers energy analytics, customer engagement, data ingestion and predictive modeling to utilities, so it had to stay available throughout.
Four things made this hard:
- One codebase, two clouds.
The same repositories had to build and deploy to AWS or Google Cloud depending on the tenant, not fork into two products. - Deep coupling to AWS services.
Storage, messaging, caching and serverless calls were embedded across backend services, web portals and a multi-site content management frontend. - A tightly interdependent backend.
A change to a shared library rippled through every downstream service, which stretched build and test cycles. - No room for regression.
Performance on Google Cloud had to match or exceed the AWS baseline, with no disruption to live tenant data.
The solution
D3V mapped each of the platform’s seven AWS infrastructure layers to a managed Google Cloud equivalent, so application logic stayed insulated from the infrastructure change.
Every AWS layer maps to a managed Google Cloud service
| Layer | AWS baseline | Google Cloud target |
|---|---|---|
| Compute | EC2 Auto Scaling groups | Compute Engine instance groups |
| Database | RDS for MySQL | Cloud SQL for MySQL |
| Object storage | Amazon S3 | Cloud Storage |
| Caching | Self-hosted Redis on VMs | Memorystore for Redis |
| Content delivery | CloudFront | Cloud CDN |
| Messaging | SQS and SNS | Pub/Sub |
| Serverless | Lambda (Java 8) | Cloud Functions + Secret Manager |
Where the platform ran self-managed components, the move replaced them with managed services, which removed host-level maintenance and added high availability. The database moved with continuous change data capture replication, so both clouds stayed in sync during testing and cutover needed no extended maintenance window.
How we did it
Four engineering patterns let the same repositories run on either cloud, chosen at deployment time.
Storage without a rewrite
Cloud Storage accepts standard S3 API requests. D3V kept the existing S3 client code and redirected it to Cloud Storage with interoperability credentials and an endpoint override. This avoided rewriting storage access across the backend services and web portals, and kept regression risk low.
Messaging with alternate code paths
Queues and notifications work differently on the two clouds, so configuration alone was not enough. D3V added environment-aware code paths: polling-based queues on AWS, Pub/Sub topics and subscriptions on Google Cloud. Topics and subscriptions are provisioned programmatically at startup.
Serverless modernization
An event-driven notification service moved from AWS Lambda to Cloud Functions, triggered by Pub/Sub push. The runtime was upgraded from Java 8 to Java 11, and credentials moved from environment variables into Secret Manager.
Web frontend refactoring
The multi-tenant content management frontend moved to Compute Engine managed instance groups, backed by Cloud SQL and Memorystore. Public assets are cached at the edge through Cloud CDN, while sensitive customer documents sit in private buckets and are served through signed URLs.
Delivery approach
The engagement followed D3V’s standard four-phase cloud migration methodology.
| Phase | Activities |
|---|---|
| 1. Assess | Workload discovery Dependency mapping Phased roadmap |
| 2. Plan | Landing zone design IAM and VPC topology Resource sizing |
| 3. Migrate | Code refactoring Dual-cloud builds Pre-production and UAT |
| 4. Optimize | Load and SLA testing CDN cache tuning Rightsizing |
Assessment mapped the dependencies between repositories first, so low-risk foundational components moved before the services that depend on them. The dual-cloud refactoring in the Migrate phase carried most of the engineering effort.
Results
- Dual-cloud capability.
Backend services and the multi-site CMS now run on AWS or Google Cloud, selected by deployment configuration. - Zero operational disruption.
Feature parity, continuous database replication and the storage transition were delivered across pre-production and UAT without affecting live customers or breaching SLAs. - Lower migration risk and effort.
Reusing the existing storage client code avoided an estimated 8–12 developer-weeks of rewriting and retesting. - A modernized baseline.
Runtimes moved to Java 11, self-hosted caches gave way to managed Memorystore, Cloud CDN took over edge caching, and credentials moved into Secret Manager. - Quality held.
New unit tests covered every cloud abstraction and alternate code path, so the dual-cloud code met the client’s quality gates.
Why D3V
This engagement combined cloud architecture with disciplined software engineering inside a legacy, tightly coupled codebase and a rigid CI/CD environment. D3V delivered a multi-cloud platform that gives the client platform agility, operational resilience and long-term technical autonomy.
D3V is a Google Cloud Premier Partner. To discuss a migration or multi-cloud program, contact the D3V team.
