Anton Beskov, Senior Software Developer

Anton Beskov

Senior Software Developer

Techletter: Moving an existing Java Web application to the Cloud Foundry Platform

“It’s easy to create and run a new cloud-native application, but migrating an existing Java Web application to the cloud might be quite complex: most applications have to be changed in a way that makes them incompatible with the old environment and thus additional risks arise. In this article, we’re sharing our experience with the migration of large Web applications, including some advice and best practices.”


Cloud computing offers a remote hardware and runtime environment for your application, where a cloud computing service provider, like Cloud Foundry, is usually responsible for infrastructure setup and management. Such services present an easy way to achieve vertical scalability – application memory, disk space and CPU quota can be increased easily, as well as horizontal scalability – where the number of application instances can be increased or decreased on the fly, all without any hardware investment from the user’s side.

A cloud platform is often considered a realistic option for newly developed applications regarding cost reduction and configuration simplicity. In any case, having new cloud applications and retaining old infrastructure for legacy applications is expensive and complicated, with risks increased. Thus, when considering moving to the cloud, companies consider migrating legacy applications to the cloud as well, to keep their infrastructure approach unified.

Such migration is often not a straightforward process, since many aspects, apart from the technical ones, should be taken care of.

In this Techletter, we focus on our experience with the migration of a large Java application to the Cloud Foundry Platform. In the following, we will address the questions which should be answered before migration as well as the technical aspects of migration.

Things to consider before migration

One may think that only technical aspects limit the feasibility of cloud migration, which we will address in the next section, but there are other questions that need to be answered even before your application is migrated to the cloud.

For example, if your application processes sensitive user data, governmental requirements might exist to store such data within the country where the users are living. Does your Cloud Foundry provider support the storing/processing of highly sensitive data at all? Where will this data be stored geographically?

Business is involved into the migration process as well: will the licensing terms and costs of the third-party software components you are using be the same for the case where the software runs in a virtual container, and not on physical hardware? If your software system requires high availability, do you need a special service-level agreement with your cloud provider?

When it comes to operational changes, your new cloud applications will probably use a new monitoring toolchain, so your processes should be set up and, most importantly, the people who are responsible for the operation services should be trained to use the toolchain efficiently. Can such training courses be organised and conducted before your new cloud application goes live?

These topics are just as important as the technical aspects, seeing as ignoring them can lead to severe problems, damaged reputation or even lawsuits.

We recommend to separate migration aspects into technical and non-technical topics (considering the questions mentioned before) and provide full answers before the very first software release.

Technical Aspects of Migration

Before migrating your Web application to the cloud, it’s good to check if your application already complies with most of the parts of the Twelve-Factor App methodology (, for example:

  • The configuration is stored in the environment variables
  • The build, release, and run stages are separated
  • The application runs as a stateless process
  • The development and production environments are almost identical

Existing applications usually need to be adapted for the cloud environment. Please note that even though our approach is based on our experience with the Cloud Foundry Platform, these aspects should remain valid for other cloud platforms too.

Architecture: A typical Web application running in the Cloud Foundry environment is able to use only one HTTP port that is accessible for the outside world, so if your application used to have more than one port for incoming HTTP requests, you will have to adapt your architecture accordingly.

Runtime: Applications in Cloud Foundry start in a pristine self-contained environment, which means you should not rely on storing any state information or log files on the filesystem where your application runs – those files will be gone after application restart. For logging purposes, consider using a Log Management Service provided by the cloud application service provider. Your Java application logging subsystem just needs to be reconfigured to use the standard output streams.

Network: Cloud Foundry provides “spaces” for running your applications – each space usually restricts all network traffic from the running applications to the outside world. If your software needs to connect to backend systems, you must create a “connectivity request” for each IP address and port you need to connect to. This has to be done only once, during the space setup and configuration. It’s better to prepare a list of the backends your application is using with their IP addresses and ports.

Complex applications may have to connect to hundreds of different backends, and you want to be sure that every connection is requested and indeed granted in the cloud, otherwise some parts of your application will not function properly. We recommend automating such connectivity checks by creating a simple script (Python or JavaScript) which can be run in your application’s Cloud Foundry space and will read a file with IP addresses and ports and check if all connections can be established.

CI/CD: In a perfect world, all software projects are built and tested on every code change using continuous integration (CI) and are immediately deployed using continuous deployment (CD). Existing projects sometimes lack one or both of these practices. It is a good idea to complement the cloud migration with setting up the CI/CD pipelines. You can even create a separate build project for your cloud application in the same repository, so that the cloud migration does not affect much of your existing build and deployment processes.

Setting up CD jobs for your cloud application helps to diagnose deployment problems earlier: for example, even though the whole infrastructure configuration should be easy, transparent and not changed by the cloud provider, be aware that this assumption of a perfect world may be wrong. Indeed, in our project, once the network provider changed firewall configuration and the CI server could not reach the cloud instances anymore, then one day our developers started using new third-party libraries which have dramatically increased application size, and deployment suddenly failed just because the application file became too big to be uploaded to the cloud. You don’t want to discover these problems a day before your shiny new cloud application goes to production.

Pic. 1 – A typical CI/CD workflow triggered on every code change

Package format: A legacy Java application often has its own deployment format – it might be a special start-up script which unpacks the application and starts it, or it even can be packetised differently, depending on the target environment: developer’s machine, CI or production server. When moving to the cloud, it’s a good idea to unify the application format so that the same application package can be run everywhere.


Some cloud migration paths suggest using the so-called “fat JAR” format for Java applications, which is fine for simple cases, but is prone to problems in large software projects. We’ve had very good experience with the “distZip” format, a zip file containing start-up script and all the JAR files needed to run the application. Such a zip file can be directly deployed and run in the Cloud Foundry. Using Gradle as a flexible build automation system allows you to easily create a distZip format file with the application: you just need to apply and configure the application plugin and the rest will be done automatically, including customisable start-up script generation for both Windows and Unix environments.


Troubleshooting: Sometimes you need to troubleshoot your application and want to see what the environment looks like – in this case you can use the Cloud Foundry command line interface (CLI) to log in via SSH to your application container and see the directories content or run some basic Linux utilities (like ‘top’ to see the current processes or ‘nc’ to test the connection to a problematic backend system). If the application crashes or does not start at all, there’s the possibility to provide a customised start-up command during deployment.


Migrating an existing Java Web application for the Cloud Foundry Platform is not always very straightforward. Our experience shows that the following steps are helpful to perform such a migration efficiently:

  • Plan the migration project in advance and involve all stakeholders, including the data protection, business and operations departments.
  • Start with a small proof-of-concept project and elaborate it iteratively to become your new cloud application.
  • Automate everything: cloud connectivity checks, code integration and deployment.
  • Use the single application file format for development, tests and production.
  • Get familiar with the Cloud Foundry CLI.

News from ERNI

In our newsroom, you find all our articles, blogs and series entries in one place.

  • 27.09.2023.

    Unveiling the power of data: Part III – Navigating challenges and harnessing insights in data-driven projects

    Transforming an idea into a successful machine learning (ML)-based product involves navigating various challenges. In this final part of our series, we delve into two crucial aspects: ensuring 24/7 operation of the product and prioritising user experience (UX).

  • 13.09.2023.

    Exploring Language Models: An overview of LLMs and their practical implementation

    Generative AI models have recently amazed with unprecedented outputs, such as hyper-realistic images, diverse music, coherent texts, and synthetic videos, sparking excitement. Despite this progress, addressing ethical and societal concerns is crucial for responsible and beneficial utilization, guarding against issues like misinformation and manipulation in this AI-powered creative era.

  • 01.09.2023.

    Peter Zuber becomes the new Managing Director of ERNI Switzerland

    ERNI is setting an agenda for growth and innovation with the appointment of Peter Zuber as Managing Director of the Swiss business unit. With his previous experience and expertise, he will further expand the positioning of ERNI Switzerland, as a leading consulting firm for software development and digital innovation.

  • data230.08.2023.

    Unveiling the power of data: Part II – Navigating challenges and harnessing insights in data-driven projects

    The second article from the series on data-driven projects, explores common challenges that arise during their execution. To illustrate these concepts, we will focus on one of ERNI’s latest project called GeoML. This second article focuses on the second part of the GeoML project: Idea2Proof.

  • 16.08.2023.

    Unveiling the power of data: Part I – Navigating challenges and harnessing insights in data-driven projects

    In this series of articles (three in total), we look at data-driven projects and explore seven common challenges that arise during their execution. To illustrate these concepts, we will focus on one of ERNI’s latest project – GeoML, dealing with the development of a machine learning algorithm capable of assessing road accident risks more accurately than an individual relying solely on their years of personal experience as a road user, despite limited resources and data availability.


  • 09.08.2023.

    Collaborative robots revolutionising the future of work

    The future of work involves collaboration between robots and humans. After many years of integrating technology into work dynamics, the arrival of collaborative robots, or cobots, is a reality, boosting not only safety in the workplace but also productivity and efficiency in companies.

  • 19.07.2023.

    When the lid doesn’t fit the container: User Experience Design as risk minimisation

    Struggling with a difficult software application is like forcing a lid onto a poorly fitting container. This article explores the significance of user experience (UX) in software development. Discover how prioritising UX improves efficiency and customer satisfaction and reduces risks and costs. Join us as we uncover the key to successful software applications through user-centric design.

  • 21.06.2023.

    How does application security impact your business?

    With the rise of cyber threats and the growing dependence on technology, businesses must recognize the significance of application security as a fundamental pillar for protecting sensitive information and preserving operational resilience.