Web application · design walkthrough

Keep the application working. Change where it runs.

A browser-facing application depends on more than its container image. Follow the web service, saved data and the configuration that connects them.

Illustrative design · proposed checks have not run. No application, data or deployment is included.

Explore the architecture ↓About product demos

Source → proposed target

Same application outcome.
Different operating model.

A team uses a web application to create a synthetic project and reopen it later. The page loading is not enough: saving, reading and access controls must still work.

Illustrative AWS sourceWhat the application depends on
ILLUSTRATIVE
  1. Browser requestsApplication Load BalancerHTTPS traffic reaches the application. Certificates, routing and health checks matter.
  2. ApplicationAmazon ECS serviceThe container serves the UI and API. Its image, configuration and identity are dependencies.
  3. Saved dataAmazon RDS databaseProjects remain available across requests. Schema, transactions and recovery need review.

Owned synthetic example · not customer infrastructure or observed traffic.

Proposed portable targetA target to validate
PROPOSED
  1. Entry point + applicationIngress + application containerReuse an approved application image with explicit routing, health and configuration bindings.
  2. Saved dataCompatible database serviceRetain the required database semantics. A container image alone does not migrate the data.

Proposed design · not deployed or tested as this application.

Preserve the outcome, not every AWS component.

Move the application service without assuming that load balancing, identity or database behaviour follows automatically.

What must still work

Checks that mean something to the team.

These are proposed acceptance criteria, not recorded results or a promise of current runner support.

1 · Required outcome

Open the application

The synthetic user reaches the expected page through the target entry point.

Proposed check · not run
2 · Required outcome

Save and reopen a project

A made-up project can be created and read back with the expected fields.

Proposed check · not run
3 · Required outcome

Keep private data private

A second synthetic user cannot read the first user’s project.

Proposed check · not run
Illustrative failure · not a measured result

The page loads, but saving a project fails.

Inspect the target database binding, schema and application configuration. Correct the dependency rather than accepting a successful health check as an application pass.

Before relying on this design

What still needs validation?

  • ALB, ECS and RDS source discovery are not currently implemented. This example explains the intended journey; it is not a supported end-to-end workload.
  • Container acquisition, approved image execution, database migration and these browser/state/authorisation checks need implementation and independent test evidence.
  • Real databases require an agreed migration and recovery plan; this illustration uses no production records or customer identities.
Check current AWS coverage →

What the handover should include

Application. Dependencies. Checks. Evidence.

A useful package needs approved application material, target configuration, a data plan, repeatable checks and deployment and cleanup instructions. This example does not include a runnable bundle.

Understand packages and evidence →