Move a Legacy App to a New Host Without a Rewrite

From the team behind aidrop.it — one workspace to build, host, and keep changing your code.

A legacy application does not need a rewrite before its first move. It needs one deployable you can name, the branch that contains it, the port it listens on, a health path, and a record of the values it reads. Build that smallest honest version first. You will learn from a running copy which modernization work is real and which work was only anxiety about old code.

Start with one deployable, not a new architecture

Pick the part of the system that can run without inventing a new boundary. A Rails app, a Node API, or a PHP service behind one web entry point is one deployable even when the repository is untidy. Keep the database where it is for the first move if changing it would turn a hosting task into a data migration.

The goal is a repeatable build, not a pretty repository. Record the branch, container port, health path, required value names, and the address that results. Those facts give the next developer a starting point they can verify. They also keep an agent from treating an unfamiliar repository as permission to redesign it, the risk behind inheriting a codebase you did not write.

Let the first build reveal the real blockers

An older application usually carries assumptions about its runtime: a writable directory, an in-process cache, a port fixed in code, or a value that only existed in somebody's shell. Do not guess around them. Give the agent the runtime contract, build once, then read the result and its log.

The build may show that the application needs a writable upload path or a database connection. That is useful evidence. It is better than changing frameworks before you know whether the existing process actually works. Read the runtime before the code so each change answers a stated constraint.

A concrete first launch

Connect your coding agent, then ask it to perform the sequence below. Replace the names and port with facts from the repository. Tell the person responsible for the project that the resulting address is public before the first build.

Create a Project named "Billing Portal". Its current job is to serve the
existing customer invoice portal.

List the repositories available to this Project. Use acme/billing-portal.
Build a Service named "web" from branch main. It is a node_http app, listens
on port 3000, and /health must answer before it is considered up.

Poll the Service until the build finishes. If it stops, show me the stage,
reason, and redacted log. Do not change the code until you can name the failed
assumption. If it succeeds, report the commit, image tag, and public address.

The first build records the branch and runtime settings for that Service. The next session should read that live record before editing anything, rather than assuming the branch head is already running. That prevents a common legacy-project mistake: fixing code that never reached production.

Keep the first change small enough to reverse

Choose a harmless user-visible change after the application answers: a label, a validation message, or one log line with a request id. Push it through the same branch and build path. Now you have tested the whole route from source to address without coupling it to a database rewrite or a framework upgrade.

Successful builds should remain identifiable by commit. If a later change fails, start the older built image rather than rebuilding an old commit, because rebuilding can produce a different artifact. A rollback should not rebuild explains why the distinction protects a legacy system.

A legacy first-launch record

Keep this in the repository or the project handover note. It works with any host and gives the next developer a concise place to start.

LEGACY FIRST LAUNCH
Repository / tracked branch:
Deployable chosen for the first move:
Entry command / runtime kind:
Container port / health path:
Values required by name only:
Data that stays where it is for now:
Public address owner informed: yes / no
First built commit / image tag:
What the build exposed:
One safe follow-up change:
Rollback condition and owner:

FAQ

Do I need to rewrite a legacy application before hosting it? No. Start by running the smallest existing deployable and write down the runtime assumptions it proves. A rewrite makes sense after you can name a specific constraint it removes, such as an unsupported dependency or a process that cannot serve the required health check.

What should I migrate first: the application or the database? Move the application first when it can safely reach the existing database. Combining a host move with a database move makes a failure ambiguous. Plan the data migration separately, with a tested restore and a compatible schema transition.

How does the first launch save developer time? It turns tribal knowledge into named settings and a repeatable path: branch, port, health check, values, commit, address, and failure log. The next developer investigates those facts instead of spending a session rediscovering them from source.

How do I start this on the platform? Install the aidrop.it connector in your coding agent, create a Project, let the agent list the repository it can access, then ask it to call service_build with the repository, branch, runtime kind, port, and health path. Poll service_get until it reports the address or a stopped build with its log.