Online store moves out of its own data center

The challenge

What was going wrong

1. 1

   Inventory what actually runs

   We listed every server, database and scheduled job, then traced which parts of the store depended on each one. This showed what to move first and what to retire.

2. 2

   Design the target setup

   We planned a cloud layout with separate environments for testing and live traffic. Infrastructure as code meant every part could be rebuilt from a script, not from memory.

3. 3

   Move in small, reversible steps

   We moved supporting systems first, then the database, then the storefront. Each step had a tested way back, and we rehearsed the final cutover on a quiet night.

4. 4

   Tune and hand over

   After launch we reviewed usage, switched off unused capacity and set budgets and alerts. The in-house team learned to change the setup through code reviews.

• Cloud hosting for the storefront

  The store runs on managed cloud services that add capacity when traffic rises.

• Infrastructure defined as code

  Every network, server and setting lives in version control and can be rebuilt on demand.

• Safe database move

  Product and order data was copied across and checked before the final switch.

• Cost visibility

  Budgets, tags and alerts show which part of the store drives each cloud bill.

• Sales events run without emergency hardware

  The team stopped buying spare servers before each peak and let the platform scale itself.

• Environments rebuilt from code

  Test and live setups now match, so surprises at release time became rare.

• Clearer view of spend

  Finance and engineering read the same cloud cost report and agree on where money goes.

• AWS Amazon cloud hosting and services.
• Terraform Defines cloud setups as code so they can be repeated.
• Docker Packages software so it runs the same everywhere.
• PostgreSQL Dependable database for complex business data.
• NGINX Web server and load balancer that routes traffic reliably.