Domain migration (what I shouldn't have done)
Tags: website, aws, route53, domainname
Published: 2023-11-21 16:52:33

---
title: Domain migration (what I shouldn't have done)
published: true
date: 2023-10-29 19:25:39 UTC
tags: Website,AWS,Route53,Domainname
canonical_url: 
---

# Introduction

For the next steps of this blog, I wanted to migrate the domain marcoaguzzi.it from the first AWS account I’ve signed to the second one (the one that actually has the real site going on, [dev.marcoaguzzi.cloudns.ph/](https://dev.marcoaguzzi.cloudns.ph/)).  
These poses a few threats:

- The registered domain should be moved to the first account to the second, and should continue serving the old site (now a placeholder with redirects)
- The hosted zone containing all the records should be migrated to the new account
- I didn’t want any downtime (little did I knew!)

# Domain migration

The registered domain migration has been easy. Following the AWS guide at [https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/domain-transfer-between-aws-accounts.html](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/domain-transfer-between-aws-accounts.html) was straightforward. Exported the domain from the first account, and imported to the second, neat.

# Moving the hosted zone

The AWS guide continued in what should have been the hosted zone migration process, but it was quite awkward: it involved exporting the hosted zone as a json file and modifying it trying to break all the possible json syntaxes. Moreover, I wasn’t sure about the records pertaining to the https certificate that display a neat lock on the address bar.

# Creating a Maintenance page

I simply create a simple html page with a maintenance message on the s3 website, still provisioned from the cloudfront distribution.  
The simple but effective template was found at [https://gist.github.com/pitch-gist/2999707](https://gist.github.com/pitch-gist/2999707)

# Starting building the new ‘prod’ site

Once the domain was migrated, I started creating the new ‘prod’ site using the same cloudformation template I had been using for the ‘dev’ site (the one that is displaying the arcticles at the moment).

## Step 1 - Generating the new stack and the change set

### Using git from AWS cloudshell

I’ve found this script that sets up the git certificate for cloning with ssh a repo in the cloudshell, which I’ve found useful to issue simple cli commands

I wanted to check wether the cloudformation stack was ok, so I started using CLI in order to create the new stack from a new changeset that I could revise:

```
aws cloudformation create-change-set --stack-name marcoaguzzi-website-prod --change-set-name first-deploy --template-body file://marcoaguzzi.json --change-set-type CREATE --parameters file://parameters-prod.json
```

I did a bunch of back and fort deletion and re-creation using the delete command

```
aws cloudformation delete-change-set --change-set-name arn:aws:cloudformation:us-east-1: ***:changeSet/first-deploy/***
```

### Step 2 - change set execution

And then finally execute the change set

```
aws cloudformation execute-change-set --change-set-name arn:aws:cloudformation:us-east-1: ***:changeSet/first-deploy/***
```

This led to a bunch of problems:

- The new created hosted zone had the dns server set up randomically, while the registered domain had the one pointed to the hold hosted zone (which I didn’t migrate)
- Due to the discrepancy above, the https certificate couldn’t be automatically validated

## Step 3 - updating the registered domain and trial and error

### The registered domain

Reluctantly, I updated the registered domain DNS to match the hosted zone ones, and that led to have the main domain, marcoaguzzi.it, not responding for one hour and a half.

### The cloudfront distribution breaks it all

After the domain matched the hosted zone, I confirmed the certificate, and cloudformation template went on creating stuff but.. the cloudfront distribution couldn’t be created because the old one was serving the same CNAME that I wanted in the new account. Cloudfront rolled back by destroying all the resources (including the hosted zone).  
I had to restart all from the beginning, including registered domain DNS update

## Step 4 - migrated domain back to life

I destroyed the cloudfront distribution in the first account (I first only disabled it, but it costed me another re-run), and run cloudformation template from the beginning, this time it all went through and the “prod” domain was still responding

# Yet to do stuff

Here’s a list of stuff to fix in order to have the new production site mimic the “dev” one (from where you’re reading this post)

- check cloudformation drifts
- reactivate lambda@edge on “prod” to align to “dev”
- add CNAME record (from [www.marcoaguzzi.it](http://www.marcoaguzzi.it/) to marcoaguzzi.it) in cloudformation
- activate logging in “prod” cloudfront

# Conclusion

Hope that this post will be of some help to anyone reading it, probably I’ll update it as long as improvement to cloudformation template will be put in place