Migrate an ecommerce storefront to Quake AI

In this migration guide, you move an existing ecommerce storefront from another provider to Quake AI. The source might be a self-hosted WooCommerce or Magento stack on AWS EC2, or a containerized storefront you export from another cloud. The target shape combines an edge reverse proxy, application VMs, self-managed Postgres, and Object Storage for product media.

Quake AI is SOC 2 attested but not PCI-DSS attested. Card data never lands on Quake AI infrastructure. Shoppers submit payment details to your external PCI-DSS payment processor. Your storefront receives payment tokens and webhook confirmations only. Keep that processor pointed at the same endpoints across the migration window.

What you will learn:

• How to map your source provider to Quake AI services before you touch production traffic
• How to stand up the migration target with a dedicated edge proxy on one floating IP
• How to sequence catalog database moves and product-media bucket sync using existing primitive migration pages
• How to cut over DNS with a concrete rollback path if checkout or catalog reads fail

Time estimate: 60 minutes (excluding large bucket transfers and database dump windows)

Prerequisites#

You need:

• Read access to the source storefront (SSH, cloud console, or export files from Shopify/WooCommerce)
• The OpenTofu CLI and credentials for Quake AI (source your OpenRC file)
• The provider concept-translation page for your current cloud, for example Coming from AWS
• A Stripe (or other PCI-DSS) processor account already wired to the source storefront

This guide links the primitive migration pages for mechanics. Read those pages when you reach each step; this walkthrough sequences them for an ecommerce workload.

Step 1: Map your source provider#

Open the concept-translation page for your current provider and note how each primitive maps to Quake AI:

Write down instance sizes, security group ports (443/tcp to the edge proxy and 5432/tcp to Postgres on private networks only), and bucket names before you provision the target.

Step 2: Stand up the target shape#

Provision the public endpoint with the edge reverse proxy, the application tiers with the three-tier app, and the database with self-managed PostgreSQL. Follow the edge reverse proxy deployment guide to configure the floating IP, domain, and backend address.

The edge proxy allocates one floating IP and obtains the storefront certificate. Keep Postgres on a private address. Point your external payment processor webhooks at the target hostname only after verification (Step 4).

Step 3: Move catalog data and product media#

Work through these primitive pages in order:

1. Catalog database. Dump the source Postgres or MySQL catalog schema and restore it into the self-managed Postgres instance the template provisions. Validate row counts for products, variants, and orders-in-flight before you proceed.
2. Product media. Sync buckets with Migrate from S3 (or the matching object migration page for your source). Update storefront environment variables so new uploads and reads target the Quake AI bucket.
3. Compute configuration. If application files or containers live on source VMs, use Migrate from EC2 for disk images or redeploy containers against the target instances.

Keep the source storefront serving traffic while the target warms up.

Step 4: Verify before cutover#

On the target hostname (use a staging DNS name or /etc/hosts override):

1. Load the catalog home page and confirm product images resolve from Object Storage.
2. Add an item to the cart and complete a Stripe test-mode checkout. Confirm the processor receives the charge and the storefront records the order.
3. Replay webhook delivery from the processor dashboard if your integration depends on async events.

If any step fails, fix data or configuration on the target before you lower DNS TTL.

Step 5: Cut over DNS and roll back if needed#

Several days before cutover, lower the TTL on your production storefront hostname to 300 seconds.

1. Add the target application backend to the edge proxy and verify its health endpoint.
2. Point the production DNS A/AAAA record at the Quake AI floating IP.
3. Watch error rates, checkout success, and processor webhooks for at least one full business cycle.

Rollback: If checkout error rates spike or catalog reads fail, repoint DNS at the source load balancer. Keep the Quake AI stack running until you diagnose the failure. Do not decommission source VMs or buckets until traffic stabilizes on Quake AI.

Step 6: Clean up migration scaffolding#

After traffic stabilizes:

• Remove temporary /etc/hosts overrides and staging DNS names
• Revoke source-cloud credentials you created only for migration
• Delete pilot buckets or snapshots at the source once you confirm the Quake AI bucket and database backups cover your retention policy

What you migrated#

You moved an ecommerce storefront workload to Quake AI by composing an edge proxy, application tier, self-managed Postgres, Object Storage, and primitive migration pages. Card capture stayed at your external PCI-DSS processor throughout.

Next steps:

• Read the Ecommerce storefronts solutions leaf for architecture context
• Review the edge reverse proxy reference for domain, backend, and floating-IP variables
• Return to the OpenTofu template library for adjacent patterns