Move your application into a container without rewriting it

We move your Lucee, ColdFusion or PHP application from classic hosting into containers without rewriting it. That lets you rebuild, update and relocate the environment. Security updates for PHP 8.2 end on 31 December 2026 (As of 2026-10).

  • ColdFusion and Lucee in production systems since 2015, PHP since 2012
  • Tested on staging first, with a fallback plan
  • Reply within one working day
An orange-outlined sheet with three lines at the top; one line branches out to three identical boxes, each with three horizontal bars

When moving into a container makes sense

The hosting provider charges a surcharge or switches off your version

Your hosting provider keeps an older PHP version available only for a surcharge, or switches it off. A surcharge buys time but does not change the fact that the PHP project no longer maintains the version. If the deadline expires within days, we start with the 48-hour emergency assessment.

Only one person knows the environment

Web server settings, PHP extensions, versions and cron jobs were set by someone at some point and never documented. If that person is unavailable, the environment cannot be rebuilt, or only with great difficulty.

Updates cannot be tested anywhere

Without a second environment, a new PHP, Lucee or ColdFusion version can only be tried on the production system. That is why the update keeps getting postponed. We design an infrastructure of servers and virtual environments tailored to your case.

A time axis with tick marks; an orange mark on the axis stands for the end of support; a dashed arc leads from a small old server across it to a new server

From a hand-built server to an environment described in files

Today your environment consists of whatever has been installed on a server over the years. In a container it is described in files: web server, runtime (PHP, Lucee or Adobe ColdFusion) and settings live in your repository.

From these files the environment can be rebuilt on any suitable server: at your site, at another provider or on a test system. The application itself normally stays unchanged. How we work with images, updates and the way back is described on the Docker page, and server configuration as code on the Ansible page.

On the left a hatched block, on the right the same block inside a container outline, a thin arrow connects the two, the container outline is orange

How we move: six steps, each with a written result

  1. Inventory of the environment

    We record versions, extensions, web server settings, cron jobs, files and uploads, sessions, mail sending and databases. You receive the inventory in writing.

  2. Definition of the environment

    We describe the environment in files and store them in your repository. Your team or another provider can then rebuild it on a new server.

  3. Running alongside production

    We start the application in a container on a staging system next to your production system. The production system stays unchanged.

  4. Tests

    We check the critical workflows and the generated documents. After a platform change, fonts and page sizes in PDF files sometimes change. The test log also records whether the environment could be rebuilt completely from the files.

  5. Changeover in a maintenance window

    We agree the plan, the time and the fallback to the old state with you in writing beforehand. Then we switch over.

  6. Runbook for updates

    You receive instructions for how you or another provider can test a new version first, then roll it out and, if necessary, revert it.

A version's end of support applies in a container as on a server

As of: 2026-10
Date Event Source
2025-12-31 PHP 8.1: end of security updates. php.net (opens in a new window)
2026-11-10 Adobe ColdFusion 2021: end of extended support. helpx.adobe.com (opens in a new window)
2026-12-31 PHP 8.2: end of security updates. php.net (opens in a new window)
2028-12-31 PHP 8.4: end of security updates. A possible target version. php.net (opens in a new window)

Stay, containerise or upgrade? (As of 2026-10)

Criterion Stay on the hosting Move into a container Upgrade the version Lucee instead of Adobe ColdFusion
Suits you if The version is supported, the backups are tested, and nothing is planned. You need an environment you can rebuild, want to test updates alongside production or are moving to another server. The platform no longer receives security updates, wherever it runs. The code is adapted where needed. You pay for several Adobe licences, and the numbers for switching add up. The code is checked for differences and adapted.
What it does not solve The knowledge still sits in one head, and updates cannot be tested anywhere. A version without security updates stays that way in a container. The environment stays hard to rebuild if nobody describes it. Lucee needs maintenance too.
Licence and costs Hosting and surcharges continue. Lucee and PHP: no licence costs. One-off effort for adaptation and tests. One-off effort for the migration and tests.

When a container is not worth it

Stay on your hosting if all three points apply:

  • The application runs on a small server in a supported version.
  • The backups pass a restore test.
  • No changes are planned, either to the application or at the hosting provider.

In that case we will not sell you a container project. Updates and hardening of the server make sense instead, as described by the Linux operations and infrastructure service.

If the application runs on a version without security updates, a container does not solve the problem either. The update comes first then, for instance following the approach on the page PHP 8 upgrade.

A system keeps running along a straight line; the branch to a new, dashed platform is blocked by an orange bar

Our engineers' experience with containers and platform changes

Containers
Docker environments for Lucee, Adobe ColdFusion and PHP
Environments
Configuration as code with Ansible, separate inventories for production and test
Platform change
Moves from Windows and IIS to Linux, with the documents tested for fonts and page sizes

How we work when moving into a container

  • Access credentials, code and documentation stay with you.
  • We switch the production system over only once the application passes on staging. The fallback to the old system stays open until operation is stable.

And if someone on our side is unavailable? We write the documentation on request. The repository is normally with you. We arrange cover on request.

More under Experience and How we work.

On the left a sheet with lines of text and a signature line with an orange tick; an arrow points to a server drawn with dashed lines on the right

The first step: legacy review with container suitability

Legacy review

For companies with a system that nobody knows well any more: before an update, before a migration or when changing service provider.

  • Inventory of versions and dependencies
  • Map of application, database, server and email
  • Risk register covering security, support and knowledge
  • Assessment of backups and restores
  • Recommendation “stay, upgrade or migrate” with an options matrix that also covers “move into a container” and “expose as an API”
  • Effort estimate in days

The price covers one system, meaning one application with its database and its server. We price further systems individually.

What the result contains

A written report with inventory, risk register, recommendation and effort estimate. The report is yours.

from €3,800 excl. VAT

Typically 5 working days

Request a legacy review

48-hour emergency assessment

For companies whose developer or service provider has suddenly left and whose system has to keep running regardless.

  • Inventory: versions, dependencies, access, backups, scheduled tasks, data sources and outgoing email
  • List of the risks that need attention immediately
  • Stabilisation plan for the first 5 days and for the first 30 days
  • Short meeting to go through the results

The result is with you 48 hours after we have access to the system. Changes to the production system and any further work happen only with your approval.

What the result contains

A written report on the state of the system, the immediate risks and the stabilisation plan. The report is yours.

from €1,900 excl. VAT

Typically 2 working days

Request the 48-hour assessment

A case from our work

  • A phone with a QR code, a file split into chunks, three parallel streams to a server with a disk and a gallery grid

    A photo upload app for wedding guests

    Wedding guests scan a QR code, open one secret address and upload photos and videos straight from the phone: no app, no account, no login. Files of up to 5 GB land on the client's own disk, and the couple watches the gallery fill up during the party. One evening, no second chance, and phones from six years back.

Questions about moving into a container

What do we gain by moving to a container?

An environment that can be rebuilt. The same version and configuration apply on the developer's machine, on staging and in production, recorded in the repository instead of in one person's head. We test new versions of PHP, Lucee or ColdFusion alongside production and can roll them back. Moving to another server or another provider also becomes easier.

A container fixes no bug in the code and does not bring an unsupported version up to date. It only makes those changes easier.

Does my application need changes for the container?

As a rule, the application's logic stays the same; the environment and configuration change. Exceptions are things tied to the old server. Examples are absolute file paths in the code, sessions stored on the local file system and services expected to run on the same server.

We record this in the inventory and tell you before the work starts what has to be adapted.

What happens to the database and uploaded files?

We treat both separately from the application. Data should survive a restart or the replacement of a container, so it lives outside the container. The database runs on its own server or in a separate container with persistent storage, and uploaded files sit in a mounted directory.

In the inventory we define where everything lives and how it is backed up. Before the switchover we check that both can be restored from the backup.

Can Adobe ColdFusion also be run in containers?

Yes, Adobe ColdFusion can run in containers. In the legacy review we check whether your installation is suited to it.

Do we have to change our hosting provider for containers?

With conventional shared hosting, Docker usually cannot be used. You need a server on which you can install software freely, for example a virtual server.

Whether your current package allows this or a change is needed, we clarify in the legacy review. You can run the server with a provider of your choice, and we set up the containers there.

Can the move to containers be reversed?

Yes. We switch over only once the application has passed testing on staging in the container. We leave the old system untouched until operation is stable. The fallback plan is part of the plan you receive in writing beforehand.

The plan deals explicitly with data created between the switchover and a return, to avoid losing any.

Who runs the containers after the move?

That is your decision. With the runbook, your own people or another provider can operate and update the containers themselves.

If you prefer, we take over operations as part of Takeover and maintenance and Linux operations and infrastructure.

Is my host's extended support an alternative to updating?

In the short term it can buy time, but it is not an alternative to the update. It applies only at the host in question and ends at the latest when that version is switched off. It also says nothing about whether your application runs on a newer version.

Saving the surcharge is not the reason to update. The surcharge is a warning sign: your version counts as end-of-life at the host. If you want to move away from classic hosting anyway, see From hosting to containers.

Where does your application run today?

Tell us the technology and version (PHP, Lucee or Adobe ColdFusion), the hosting provider or server and the reason. We reply within one working day.

Fields marked optional can stay empty.

Reply by email

For a call back we only need your phone number: emergencies around the clock, otherwise within one working day.

Which system, which technology, what do you want to achieve? Please do not send passwords or confidential documents.

Reply within one working day · without obligation

We use your details only to answer your enquiry. Prownex IT Services Sp. z o. o. is the controller. Retention and your rights are described in the privacy policy.