Old Chronos
1 containerMonolithic by design
Frontend and backend live in the same project and deploy as one application container.
Backend+Frontend
Internal migration briefUpdated 10 July 2026
Production infrastructure renewal
A safer path to a repeatable Chronos platform.
Build the replacement production host in parallel, containerize the database layer, automate release delivery, and reserve downtime for the final sync and traffic switch only.
2application generations
2VM environments
3application containers per VM
12shared schemas
Manualproduction deployment today
01 · Executive overview
Two application generations. One shared operating surface.
Chronos runs Old and New side by side in both environments. The migration renews how production is hosted and operated; it does not replace the Old Chronos application as part of this plan.
New Chronos
2 containersSeparated for clearer delivery
An Angular frontend calls a Spring backend over an API; each runs as its own container.
Angular frontendAPISpring backend
Old Chronos New Chronos Direct-on-VM database
EntryUsersOld application route
Old ChronosSingle containerBackend + frontend
reads / writesmonolithic projectShared layerDatabaseInstalled directly on VM
not containerizedEntryUsersNew application route
New ChronosAngular frontendFrontend container
APINew ChronosSpring backendBackend container
reads / writesShared layerDatabaseInstalled directly on VM
not containerized Pipeline deployment
Development VM
10.10.10.106Both application generations deploy to the development VM through their active development branches.
- Old branch
dev- New branch
development
Development host boundary
10.10.10.106Container 01Old ChronosBackend + frontend
Container 02New frontendAngular application
Container 03New backendSpring application
Host serviceDatabaseDirect VM install · not containerized
04 · Delivery & configuration
Development is automated. Production is still manual.
The release branch is consistent across both generations, but configuration and development branch conventions differ sharply.
Old ChronosHardcoded configuration
ApplicationConfig.javaconfig.jsutils.jsDevelopment
devPipeline → 10.10.10.106Production
releaseManual → 10.10.10.107Unused branch
DA_STRRC2_AGGIUNTA_X-GRUPPONew ChronosEnvironment-aware configuration
Backend · Spring
application.ymlapplication-prod.ymlFrontend · Angular
environment.dev.tsenvironment.prod.tsDevelopment
developmentPipeline → 10.10.10.106Production
releaseManual → 10.10.10.107Target delivery patternrelease → build immutable image → deploy with Dokploy → smoke test → retain previous image
05 · Shared data layer
Twelve schemas bind the platform together.
The known schema set is used by both Old and New Chronos in development and production. Exact read/write ownership remains a validation item.
Known schema inventory12 schemas
06 · Target state & execution
Move the operating model, then move traffic.
The plan performs every reversible activity on an isolated replacement host before opening the production maintenance window.
10.10.10.107
- Three application containers
- Database installed on the host
- Manual release deployment
- Shared content at
/var/www/html/bo
parallel preparation
Validated before cutover
- Three application containers retained
- Database services containerized
- GitLab CI + Docker + Dokploy
- Copied content; Garage only if proven
Eight phases
Execution sequence
Open any phase to see the objective, validation gate, and safe exit path.
01Provision the new serverCreate the replacement production host without changing live traffic.Parallel build
Actions
Baseline OS access, network rules, storage, Docker, Dokploy, security, monitoring, and log access.
Validation gate
The host is reachable, secured, observable, and ready to accept isolated workloads.
Rollback / safe exit
Rebuild or correct the new host; the current production server remains untouched.
02Prepare runtime servicesCreate containerized databases and deployment targets for every Chronos component.Target runtime
Actions
Prepare the Old Chronos container, New Chronos frontend and backend targets, database volumes, networks, and Dokploy definitions.
Validation gate
Containers start cleanly, persist data correctly, and expose only the required service paths.
Rollback / safe exit
Recreate containers, volumes, or Dokploy targets before any production cutover.
03Copy shared contentMake /var/www/html/bo available on the new host while the existing copy stays authoritative.No outage
Actions
Copy the content, preserve permissions and ownership, then validate read/write behavior from both Chronos generations.
Validation gate
Old and New Chronos can read and write the content paths required by their workflows.
Rollback / safe exit
Repeat rsync or copy from 10.10.10.107. Do not make Garage authoritative until compatibility is proven.
04Restore a production database copyValidate the new database containers with realistic data before the maintenance window.Rehearsal data
Actions
Back up the current production databases, restore all required schemas on the new host, and record elapsed time.
Validation gate
Checksums or logs are clean, all schemas are present, and applications connect successfully.
Rollback / safe exit
Drop and recreate the new database containers, verify the backup, and restore again.
05Add release CI/CDReplace manual production steps with a common, traceable release pipeline pattern.Repeatable delivery
Actions
Use GitLab CI to build immutable images from release, tag artifacts, deploy through Docker/Dokploy, run smoke checks, and retain the previous image.
Validation gate
Each release branch can build and deploy to the isolated new host without manual production work.
Rollback / safe exit
Disable the production jobs and retain the current manual deployment procedure as a temporary fallback.
06Validate both applicationsProve the complete application surface against restored production data and copied content.Go / no-go gate
Actions
Run smoke and connectivity checks for Old Chronos, New Chronos frontend, New Chronos backend, databases, configuration, and shared content.
Validation gate
Both generations pass the agreed checks while isolated from production traffic.
Rollback / safe exit
Correct configuration, redeploy containers, or restore a clean data snapshot before repeating validation.
07Execute final cutoverLimit the outage to the final data sync and traffic switch.Planned downtime
Actions
Freeze production writes, take final database backups, restore the latest data, run the content delta sync, switch traffic, and execute smoke tests.
Validation gate
Traffic reaches the new host, critical paths pass, data is current, and monitoring remains healthy.
Rollback / safe exit
Return traffic to 10.10.10.107 and restart old services. Assess any writes made after the switch before reconciling data.
08Stabilize and retire the old hostHold a verified rollback path until the replacement production host is accepted.Observation window
Actions
Observe the new host, monitor errors and performance, retain 10.10.10.107 intact, then decommission it after formal acceptance.
Validation gate
The agreed observation window closes with stable service and signed acceptance criteria.
Rollback / safe exit
Rollback remains available until acceptance; retirement does not mean retiring the Old Chronos application.
Downtime strategy
Only the final sync belongs inside the outage.
Build, restore, deploy, validate, pre-copy content, and measure actual backup/restore duration.
Stop writes, take the final backup, restore, delta-sync content, switch traffic, and smoke test.
Monitor the new host while keeping 10.10.10.107 intact until acceptance.
Acceptance gates
Done means observable and reversible.
Each milestone turns an activity into evidence required for the next step.
New server ready
Docker, Dokploy, networking, storage, monitoring, and baseline security are configured.
Database containers ready
Every required schema restores successfully and both applications can connect.
Shared content available
/var/www/html/bo is present with verified paths, permissions, and read/write behavior.
Release CI/CD ready
Release branches build and deploy traceable images without manual production steps.
Application validation complete
Old and New Chronos pass the agreed smoke tests on restored production data.
Cutover complete
Final restore and delta sync are complete, traffic is switched, and smoke checks pass.
Old server dismissed
10.10.10.107 remains available through observation, then is decommissioned after acceptance.
To confirm before execution
Open decisions
These items are not established by the source material and should remain visible until owners agree them.
Replacement host
Identity, sizing, storage, network, and security baseline.
Database mechanics
Engine/version, backup tooling, restore sequence, and measured duration.
Traffic switch
DNS, proxy, routing mechanism, TTL, and rollback timing.
Garage decision
Compatibility, operational ownership, migration effort, and fallback.
Release ownership
Authoritative repositories, registry, secrets, approvals, and pipeline owners.
Acceptance window
Go/no-go signatories, smoke-test checklist, thresholds, and observation length.
07 · Source material
Diagrams and working documents.
The site rebuilds the core flows for readability while preserving the original source material for detailed review and provenance.
Diagram
Overall application flow
How users reach each application generation and the shared database layer.
Open full size
Diagram
Deployment topology by VM
The matching container and direct-on-host database layout in development and production.
Open full size
Diagram
Git, deployment & configuration
Branch flows, deployment modes, and the configuration split between both generations.
Open full size
Diagram
Original architecture diagram
The initial source view retained for provenance.
Open full size