AWS migration

Move to AWS without taking your application offline

We move live applications to AWS from Azure, other clouds and on-premises servers. We build the new platform in code next to the old one, test it against real traffic patterns and rehearse the switch, so your customers don't notice the day it happens.

How it's priced
Fixed-price project
Timeline
Set after we review your current platform
Where
Panama City, FL · serving the US

Who it's for

Who we build this for

  • Companies on Azure that want to move to AWS
  • Teams whose hosting was set up by hand and is documented nowhere
  • Businesses that can't afford a maintenance window, such as booking, ordering and payment platforms
  • Organizations leaving aging servers or a hosting provider they have outgrown

Problems we solve

What's getting in your way, and how we fix it

  • A platform nobody fully understands

    We start by documenting every running service, scheduled job, credential and DNS record. Migrations usually go wrong on the things nobody wrote down.

  • Fear of downtime

    We run the new platform alongside the old one and test every part of your application against it before any customer is moved.

  • A cutover that depends on luck

    We rehearse the switch in advance, including domain records and certificates, and write down the timings. The real cutover repeats the rehearsal.

  • Infrastructure that only exists in a console

    We define the new platform as code, so it can be rebuilt identically at any time and every later change is reviewed like any other code.

What you get

What's included, in writing

Your proposal lists every deliverable, so you know what you're paying for before we start.

Technology we use

  • AWS
  • Azure
  • Terraform
  • RDS
  • ECS
  • CloudFront
  • Route 53
  • GitHub Actions
  • Written inventory of your current platform
  • Migration plan with a rollback at every step
  • AWS architecture defined as code
  • Separate staging and production environments
  • Database migration with verified data
  • Rehearsed cutover with recorded timings
  • DNS, SSL certificates and CDN moved across
  • Monitoring, backups and alerts from day one
  • Automated deployment pipeline
  • Documentation and handover, or ongoing hosting

How we work

Four steps from first call to launch

You sign off on scope and price before we start, then see working progress every week.

Our process in detail
  1. Step 1

    Discover

    We learn your business, users and goals, then agree on scope, budget and what success looks like, in writing.

    1 to 2 weeks

  2. Step 2

    Design

    We map the user journeys and design the interface, and you sign off on a clickable prototype before production code starts.

    1 to 4 weeks

  3. Step 3

    Build

    We build in short cycles and give you a live preview link from the first week, so you can watch the software take shape.

    3 to 12 weeks

  4. Step 4

    Launch and support

    We handle the launch, monitoring and handover, then stay on to host, support and improve what we built if you want us to.

    Ongoing

Our work

All our work
  • tobook · Hospitality and booking

    Moving a live booking platform to AWS, without a minute offline

    Read the case study
  • Supersonic Phonic Friends · Education

    Rebuilding a phonics platform in time for the new school year

    Read the case study

Questions

AWS migration questions

Something else on your mind? Email hello@panamagulf.com.

Will our application be offline during the move?

We plan every migration for zero downtime. Our team moved tobook's live booking platform from Azure to AWS while bookings kept arriving, with no time offline. That project was delivered through Hatcha, our UK sister company.

Can you migrate from Azure to AWS?

Yes. We map each Azure service you use to its AWS equivalent, rebuild it in code and move your data across. Most Azure App Service, SQL Database, Storage and Functions workloads have a direct AWS counterpart.

What if something goes wrong on the day?

The old platform stays running until the new one has proven itself, and every step of the plan has a written rollback. If a check fails, we switch back and you carry on as before.

Do we have to rewrite our application?

Usually not. Most applications move with configuration changes and no rewrite. If part of your code depends on something only your current provider offers, we tell you during the review, before you commit to anything.

Who runs it after the migration?

Your choice. We can hand over a documented platform to your team, or keep running it for you with monitoring, backups and security updates on a monthly retainer.

Have a project in mind?

Tell us what you're planning and we'll reply within one business day. You can book a free 30-minute call with Louie as soon as you've sent it, and we'll follow up with a written estimate.