---
# System prepended metadata

title: Monolith migration

---

# Monolith migration

## Context
We have decided to migrate the existing `submit`, `data-frontend` and `data-store` into a single service in order to simplify our architecture and speed up development

## Challenges
The existing data-store is modelled as a 'backend' service and therefore not exposed on the public internet.

Copilot does not let you change an existing 'backend' service to a 'Load-balanced web service' therefore we need to create a new service as part of the migration (ref: https://github.com/aws/copilot-cli/issues/5833)

Furthermore, as the backing-services (S3 and Postgres) are tightly coupled to the existing service, they will be destroyed when the existing data-store service is deleted

Therefore in effect we need to do a full migration to a new service.

In addition as the DNS is controlled by IT we don't have a way currently to simultaneously expose the existing and new service (on the public internet)

## Production migration

Migrating to production has additional challenges:

* Post-Award on Production currently sits in a different VPC than Pre-Award, we want to take the opportunity to re-create it in a shared VPC with pre-award to enable networking between them in future
* If we tear down the existing Copilot environment we will lose the existing Cloudfront distribution which is referenced in DNS, so we would need to co-ordinate with IT to update this
* If we have downtime on production, we will need to co-ordinate this with stakeholders



### Prod migration options

#### Deploy post-award service in existing pre-award app
##### Pros
* Straightforward to deploy
* Resolves inter-app networking issues without further configuration

###### Cons
* Moving to pre-award app will switch to its Cloudfront distribution which will require a DNS change (Unless we can figure out a way to retain the existing cloudfront distribution and re-point it to the pre-award load balancer?)
* Potentially two tightly coupled, e.g. a break in the pre-award environment would affect post-award services
* Different than current setup in pre-prod envs

#### Deploy post-award app in new app in existing VPC

##### Pros
* Replicates existing setup on dev and test
* Possible to connect to pre-award services by adjusting security groups (using Service Discovery endpoint)

##### Cons
* Additional config needed for networking
* Service Discovery is less robust than Service Connect for networking


#### Deploy post-award app in separate VPC

##### Pros
* Clean separation between environments
* Possible to connect to pre-award services using VPC Peering (in theory)

##### Cons
* Additional config needed for networking
* Different than current setup on dev and test

