Project vps-move-small-stack-off-legacy-server · revised 11 October 2026
Project
Move a small stack off a legacy server onto a new VPS set to a documented Linux baseline
Your containerised app, PostgreSQL database and certificate move from a legacy server to a new VPS you control, rehearsed first, with the old server kept untouched as the way back.
This asks for a proposal by email. Nothing is charged, and nothing starts, until you have agreed the scope, the price and the terms in writing.
The result you are buying
A legacy server holds more than its app: scheduled jobs, certificates, files outside the app directory, firewall rules, mail settings and secrets in odd places. A move that copies the app but misses a job or a certificate fails days later, when nobody remembers what the old server did. The inventory has to come before anything moves, and the old server has to stay available until the new one has earned trust.
Who it’s for: A founder or small team whose app runs on an old server that nobody wants to touch: out-of-date operating system, an unknown setup, and the one person who knew it has left.
Usually starts when: The operating system has reached the end of security support, the provider is retiring the plan, or an incident showed that nobody can rebuild the server.
The result: The agreed stack, up to four containerised services and, if there is one, a single PostgreSQL database, runs on a new VPS you control behind HTTPS, with every item on a written inventory of the old server moved, replaced or retired by your decision. The cutover has a rehearsed way back and the old server is left untouched for the agreed time. You hold all keys.
How the work fits together
The project is complete when every item on the inventory is moved, replaced or retired in writing, the required parts pass their own acceptance checks, the cutover checks pass on the new server, and you sign off. You accept the finished move, not each internal step.
Harden one Linux server: key-only SSH, a firewall and automatic security updates Job Included
One Debian or Ubuntu server gets key-only SSH, a deny-by-default firewall and automatic security updates, each checked from outside. It is not a penetration test or a certification.
One new server
The new server starts from key-only SSH, a firewall and automatic security updates.
Deploy one Docker Compose app to your VPS with HTTPS and a health check Job Included
One Docker Compose app runs on a VPS you own behind HTTPS on your domain, comes back after a reboot, and has a health check you can read, plus the steps to redeploy it.
One Compose project
The app, which must already run in containers, runs on the new server behind HTTPS with a health check.
After: Linux server baseline
Move one PostgreSQL database to a new host with a tested restore Job Optional
One PostgreSQL database moves to a new server with its roles and data. A restore is rehearsed first, rows and counts are checked, and the cutover has a written way back.
One PostgreSQL database
Included only when the database is PostgreSQL and the app uses it. Any other database engine is outside this project.
After: Compose app on a VPS
Stop logs filling the disk: rotation and size limits on one server Job Included
Container, journal and application logs on one Linux server get size limits and rotation, so the disk stops filling. A growth test shows the limits working, and nothing outside the logs is deleted.
One new server
Log limits are set on the new server before cutover.
After: Compose app on a VPS
Move one app's secrets out of its env file into your platform's secret store Job Optional
One app stops reading secrets from a plain env file and reads them from its platform's secret mechanism. It is tested starting from the new source, and you get a rotation checklist and keep every key.
One app, up to ten secrets
Secrets move out of the old env file, and you rotate the real ones with the checklist.
Run one process as a systemd service that restarts itself and logs Job Optional
One long-running process starts at boot, restarts after a crash within limits you set, runs as its own user and writes logs you can read, with the unit file tested.
One process at a time
Used for a helper process on the old server that does not run in a container (the app itself must be containerised).
Keep one Linux server patched and reviewed, month after month Standing service Optional
Each month one Linux server has its automatic updates checked, the rest applied in a window you approve after a snapshot, its services, disk, certificates and logins checked, and a short report.
Offered afterwards if you want the new server kept patched and reviewed.
How an engagement works
The price covers the agreed inventory and stack only. A service found later that is not on the inventory is added in writing and quoted before work on it starts.
How it starts
You send a short description of the old server and the stack, never logins or data. If you want, you also run a few read-only commands that we name and send us the output after you have read it.
From that description we write the proposed scope, a fixed price for the services and database you describe, and the terms.
You agree the scope, the price and the terms in writing. No access to any server is arranged, and nothing starts, before then.
After agreement, a secure handoff and a read-only route to the old server are agreed, created by you and revocable by you, and we write the inventory with a proposed decision for each item.
Items on the inventory that are not in the agreed list are added in writing and priced before any work on them starts.
We build and rehearse on the new server, send each part for your acceptance, and agree the cutover window.
We run the checks after cutover, hand over the runbook and leave the old server untouched until the agreed date.
Who decides what
You choose the provider, own the accounts and make the DNS changes. You approve the cutover and the later shutdown of the old server. We do not hold production credentials between steps.
Handover
You receive the configuration, the runbook, the inventory with decisions and the check evidence. Anything left unfinished is handed back with notes.
Sharing your product safely. Send a description of the old server and stack. Only after you agree the project in writing is a read-only inventory route agreed; rehearsals use masked data prepared in your environment, and access is through accounts you create and revoke.
What is included, and what is not
- The inventory with a moved, replaced or retired decision per item and the reason
- The running new stack with its configuration, runbook and check evidence
- The cutover plan, the way-back plan and the final report of what was checked
Included
- An inventory of what the old server does, made after you agree the project in writing: services, scheduled jobs, certificates, files, open ports, accounts and secrets, with a decision for each item
- A new VPS at a provider you choose, set to the Linux baseline, and the containerised stack running on it with a health check
- If the database is PostgreSQL: the database moved with a rehearsal restore, comparisons and a write-freeze cutover
- A cutover plan with DNS changes made by you, a certificate route for the live name, a post-cutover check period and a way back to the old server. The checks are rehearsed on a temporary hostname that you point at the new VPS; at cutover the live name is covered either in a short window you approve in which it has no valid certificate, or by you copying the existing certificate across yourself, or by a DNS-challenge route that is quoted separately
Not included
- Changing application code, containerising an app that does not already run in containers, or upgrading the application's framework
- Database engines other than PostgreSQL: a MySQL or other database is declined here and can be quoted separately
- More than four services, several servers or zero-downtime replication
- Email servers, or any service that sends or receives mail for your domain
- Buying the new VPS, domain registration or provider charges, unless the written proposal includes them
- Decommissioning the old server, which you do after the agreed period
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
Every inventory item has a written decision of moved, replaced or retired, and every moved or replaced item has evidence that it works on the new server.
Evidence: The inventory table with a decision and an evidence link per item.
Each required part passes its own acceptance checks on the new server.
Evidence: The check evidence for the baseline and the Compose deployment.
After cutover the application works on the new server for the agreed observation period, the health URL passes and a test record is written and read back.
Evidence: The health check results over the period and the test record.
The old server is unchanged after cutover and the way-back plan has been rehearsed.
Evidence: The old server's unchanged state check and the rehearsal result.
You sign off on the finished move.
Evidence: Your written acceptance.
Sign-off. You accept each part and then the finished move. The old server stays in your hands until you decide to shut it down.
If it fails. An item we cannot move safely is named with the reason and what it would take, and is taken off the list with a matching change to the price. If the cutover checks fail, we go back to the old server and you are not charged for a cutover that did not work.
When it fits, and when we stop
It fits when
- You can describe the old server's purpose, and a person on your side can answer questions about what each service is for
- The app already runs as containers, meaning images or a Compose file exist, and any other process on the server is one we can supervise with a service unit
- The database, if there is one, is PostgreSQL and small enough to dump and restore in the write-freeze window you can accept
- After agreement, a read-only inventory route to the old server can be agreed, or someone on your side runs our inventory commands and sends the output
- A provider console, rescue mode or snapshot restore works on the new VPS, so a mistake in SSH or the firewall cannot lock you out
- You will create the new VPS account and make the DNS changes, first for a temporary hostname and then for the live name
We stop and tell you if
- The app does not run in containers and has no container build, so it would have to be containerised first
- The database is not PostgreSQL
- The old server holds data of unknown origin that nobody can classify and the old server cannot be kept
- The stack needs more than one server, hardware we cannot reproduce or a special licence
- Signs of compromise on the old server, which need investigation before any move
- The old server must be switched off before the new one is proven
- The live name serves a site that cannot tolerate a short period without a valid certificate at the cutover, and you do not want to copy the existing certificate across yourself or pay for the separately quoted DNS-challenge route
What could go wrong
Until the agreed date the old server is unchanged. Pointing the DNS name back and re-enabling writes restores the earlier arrangement. The plan states the point after which a return would lose writes made on the new server.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| A duty of the old server, such as a scheduled job, is missed and fails days later. | Inventory scheduled jobs, certificates, files and accounts first, and agree a decision for each before anything moves. |
| Data is lost if the old server is switched off early. | Keep it untouched until the agreed date and check the new database before anyone decommissions the old one. |
| The live name has no valid HTTPS certificate for a short time at the cutover, so browsers warn visitors, and the DNS-challenge route that avoids this is an extra. | Everything is checked on a temporary hostname first and the issuance time is measured there. The live name is switched only in a window you approve, or you copy the existing certificate across yourself so the name is covered from the first moment, or a DNS-challenge route is quoted separately before the cutover. |
| DNS caching sends some visitors to the old server after the switch. | Lower the record lifetime in advance, keep writes frozen on the old server, and plan for the old answer to linger. |
Each part is reviewed separately from the work that produced it, and you accept the finished move. No human supervisor is included unless the proposal names one. At launch the work is largely automated, and we say so.
Questions
What if nobody knows what the old server does?
That is why the inventory comes first in the work, once you have agreed the project in writing. We read it through a read-only route and propose a decision for each item. Items nobody can explain are flagged, and the old server stays available.
Will there be downtime?
The database cutover uses a short write freeze. The rehearsal measures it and we give you the figure as an estimate, not a promise. If the live name already serves a site, it may also have no valid certificate for a short window you approve at the cutover, unless you copy the existing certificate across yourself or take the separately quoted DNS-challenge route.
Do you move email?
No. Mail servers and mail settings are not in this scope.
Who holds the keys?
You do, for the old server, the new VPS, the domain and the secrets.
Do you move a MySQL database or an app that is not in containers?
Not in this project. It covers an app that already runs in containers and a PostgreSQL database. Say what you have in the enquiry and we will tell you what fits or quote it separately.
Send an enquiry
Send us
- What the old server runs, its operating system release and the provider
- The services, whether the app already runs in containers, the database engine and its approximate size
- The date the old server will be switched off or lose support, if any
- Do not send logins, keys, dumps or customer data in the first enquiry
Later, once you agree
- A read-only route to inventory the old server, agreed only after the written agreement
- A new VPS account that you control with a working console or snapshot route, and a domain you can change
- Masked rehearsal data prepared in your environment, and the person who accepts each part
- A company-controlled secure handoff agreed before access: no live passwords, keys, private code or customer records by ordinary email.
You own the old server, the new VPS, the domain and all data and keys. Once the written agreement is in place, we inventory the old server through a read-only route you create and can revoke, rehearse on masked data in an environment you provide, and apply live steps only through time-limited accounts that you create and revoke or by handing you the change set. We never hold production credentials between steps.
Email fallback: open your mail app
If website submission is unavailable, review and send the fallback email yourself. An email fallback is not a website receipt. Or write to hello@syntheticindustry.ai with “vps-move-small-stack-off-legacy-server” as the subject.