+48 501 250 220

Use your monolith as a web service and build new software beside it

Your legacy system works and holds rules nobody wants to rewrite. We expose its logic as a web service and close known vulnerabilities in a single pass. Comparison tests check whether behaviour stays the same, and the new system is built beside it in the new stack.

Request a legacy review (including API suitability) See the migration and modernisation service
  • ColdFusion and Lucee in production systems since 2015, PHP since 2012
  • REST and SOAP interfaces
  • Reply within one working day
A large hatched block with an orange-outlined opening on its right side; five thin lines lead from the opening to five small squares

When a legacy system makes sense as a web service

These three situations argue for continuing to use the legacy system as a web service.

A new frontend or application is meant to use the logic

Your legacy system calculates, validates or produces something that a new frontend, a new application or a new partner also needs. Building the logic a second time would be expensive, and the two versions would drift apart.

A test report or a client request names vulnerabilities

A professional penetration test or a questionnaire from a client names weaknesses such as cross-site scripting or SQL injection. A rewrite often takes years in this situation, yet the vulnerabilities should be closed sooner. If the result is urgent or the system unknown, we start with the 48-hour emergency assessment.

The team wants a new stack, but the rules exist only in the code

The old system holds rules nobody has written down. If everything is rewritten, they are easily lost.

A hatched block, the old system, in the middle; three reasons point at it: a new front end as a window with an orange line, a test report and a stack of new building blocks

One entrance to the old system, new software built beside it

The old system stays in place as one block and gets a clean entrance: an API. New applications and frontends call it and no longer depend on the old code.

This is how new software grows step by step beside the old system. Specialists call this approach the strangler fig pattern (opens in a new window).

A large hatched block with an opening outlined in orange, from which thin lines lead to five small nodes

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

  1. Review

    We clarify which functions make up the system's value, such as rules, calculations and documents, and which are interwoven with the user interface. The result is the function map: what we provide as a service and what stays in the old system, with reasons.

  2. One-off hardening

    We close known vulnerabilities with the aim of leaving the function unchanged, and compare the results before and after the change. The report states what we fixed, what remains open and why.

  3. API

    We expose the logic as an API, as REST with JSON or as SOAP with XML, with authentication, rate limiting and logging. The description contains endpoints and examples of requests and responses.

  4. New software beside the old system

    New functions are built in the new stack, which calls the API. The old system keeps running meanwhile. The plan records the order of the stages and the fallback if a stage does not hold up.

  5. Replace where it pays

    We replace individual parts of the old code only when the effort of operating or changing them exceeds the effort of replacing them.

  6. Runbook

    It describes how the API is operated, monitored and updated, including by your own team or another provider.

Rewrite or use as a service?

Criterion Use as a service Rewrite Leave unchanged
Suits you if The logic works and is valuable, known vulnerabilities need closing, and a new stack is to use it. The framework is no longer maintained, there are no tests, and the business rules can be written down. The system is stable, on a supported version, and nobody needs a new stack.
What changes We harden the old system once and give it an API. New software is built beside it. Everything is built anew. Rules and data move into the new system. Nothing.
Limits Not every system is suitable. The review shows it. Until the replacement goes live, two systems run, and rules nobody wrote down can be lost. New applications cannot use the logic, and known vulnerabilities stay open.

What we do not promise

  • Not every system can be used as a service. If the logic is interwoven with the user interface, we separate the two first. The review shows this.
  • The one-off hardening is not a penetration test, not a certificate and not a guarantee that no vulnerabilities remain. We do not carry out penetration tests. We fix the vulnerabilities that reports name or that we find in the review.
  • The comparison tests show unchanged behaviour only for the workflows tested.
  • We name a saving compared with a rewrite only once the review has put a figure on the effort.
A frame holding three boxes for what is part of the work; outside it a dashed box for what is not; the stretch of the frame between them is orange

Secure access to the old system

The API should be the only access from outside into the old system and should sit behind a firewall. On request we place a web application firewall (WAF) with rules for your application in front of it. This lowers the risk but does not remove it, and it does not replace fixing the vulnerabilities.

How we secure network, servers and administrative access is described by the Linux operations and infrastructure service.

Three lines from the left run into a narrow gate outlined in orange; from there a single line leads into a large hatched block, the old system

Our engineers' experience with legacy systems and interfaces

System types
Platforms for loan processing, mortgage financing and leasing, and systems that generate documents and contracts

How we work on your old system

  • Code, access credentials and documentation stay with you.
  • We change the old system only after your approval, with comparison tests and a fallback plan.
  • We also tell you when using a service is not worth it.

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 API 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

Questions about the legacy system as a web service

Do we have to rewrite our system to use a new stack?

No. If the old system is running, we expose its logic as an API and close known security gaps as a one-off step. Its behaviour is meant to stay unchanged, and comparison tests check that. We then build the new part alongside it in the new stack, and it uses that API.

A rewrite is rarely worthwhile. It becomes an option when the framework is no longer maintained, there are no tests and the business rules can be written down. The legacy review clarifies whether that applies to you.

Will the API change the behaviour of the old system?

The aim is for the functions to stay unchanged. Before we change anything, we record the results of the tested workflows. Once the system has been secured, we compare them with the earlier state. That way deviations show up immediately.

For workflows that nobody has tested, no guarantee is possible with long-running software. We therefore agree with you which workflows count.

Do you build and integrate APIs (REST, SOAP)?

Yes. We build APIs and connect systems, with REST and JSON as well as SOAP and XML, including the synchronisation of data between applications. Typical use cases are described under Development and integration.

Can you take over a system that has no documentation?

Yes, that is what the legacy review is for. First we record what is there: versions, dependencies, scheduled tasks, data sources and email routing. We also check whether the backups can be restored.

That we do not yet know your system is the normal starting point, not an obstacle. Only with the findings can we say what the system needs and what ongoing support would involve. The report is yours.

Who maintains the old code after it has been secured?

That is your decision. Code and documentation stay with you, and with the runbook and the API description your team or another provider can carry on.

On request we take over ongoing maintenance as part of Takeover and maintenance.

How long does it take to make a legacy system available as a service, and what does it cost?

A reliable figure is only possible after the legacy review. Duration and cost depend on how cleanly the logic is separated from the user interface. They also depend on how many functions you need as a service and how many gaps have to be closed.

The legacy review estimates the effort in working days. After that we send you an offer, before you commission anything.

Do we need a different server for this?

Usually not. We run the API on the existing server or in front of it. It sits behind a firewall and, on request, a web application firewall (WAF) with rules that fit your application.

If the system runs on a platform without security updates, an update or a move has to be considered anyway. The legacy review covers that too.

Is a WAF enough?

Not on its own. A web application firewall (WAF) filters typical attacks in front of the application and buys time. It does not close a vulnerability in the code. That is why we combine it with fixing known vulnerabilities, network segmentation and administrator access through a VPN only.

A WAF with rules written for your application triggers fewer false alarms and protects better in practice than the default configuration. If the code cannot be changed quickly, a WAF with isolation is a stop-gap until the update. The risk then falls but does not disappear.

Which legacy system should live on?

Tell us the technology and version, what the system does and what new software should access it. 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.