---
title: "Comment by StackShortlist on \"How to Migrate an Application from AWS to GKE [Full Book]\" | Hashnode"
description: "Keeping PostgreSQL on AWS and shifting traffic a few percent at a time behind the same public URL is a realistic way to structure a migration, since it avoids m"
url: "https://hashnode.com/posts/how-to-migrate-an-application-from-aws-to-gke-full-book/6ad245772c56514e6fd78db7/comment/6ad2b959a305ffe669188f2d"
---

[Discussion](https://hashnode.com/posts/how-to-migrate-an-application-from-aws-to-gke-full-book/6ad245772c56514e6fd78db7)

Comment [How to Migrate an Application from AWS to GKE \[Full Book\]](https://hashnode.com/posts/how-to-migrate-an-application-from-aws-to-gke-full-book/6ad245772c56514e6fd78db7)

[StackShortlist](https://hashnode.com/@veristria)

[Oct 16](https://hashnode.com/posts/how-to-migrate-an-application-from-aws-to-gke-full-book/6ad245772c56514e6fd78db7/comment/6ad2b959a305ffe669188f2d)

Keeping PostgreSQL on AWS and shifting traffic a few percent at a time behind the same public URL is a realistic way to structure a migration, since it avoids moving the hardest piece on day one. Putting 'Prove a Retry Never Charges Twice' in Part 1, before any cloud work, is a nice touch for a payments app. Recording the AWS baseline before planning the move also gives the later load tests something concrete to compare against.