Reliva, a logistics software company running a multi-node application environment, needed its application, database, and supporting services migrated from Jelastic PaaS to CloudStack IaaS. The migration had to preserve live route and tracking operations, rebuild platform-dependent connections, maintain strict network isolation, and ensure that no other customer environment under the same reseller account was affected.
Reliva’s logistics platform depended on a multi-node cloud architecture supporting route planning, live tracking, fleet coordination, databases, and background services. Migrating this environment from Jelastic PaaS to CloudStack IaaS meant moving more than virtual machines or application files. The application tier, database tier, internal networking, connection strings, scheduled jobs, and supporting services all had to continue working together after migration.
The challenge became more complex because Reliva’s infrastructure was managed under a shared reseller account containing other customer environments. The migration therefore had two equally important requirements: move Reliva’s complete application stack without interrupting its live logistics operations, and preserve strict network, billing, provisioning, and access isolation so that no other customer on the reseller account was affected.
A conventional lift-and-shift approach would not have been enough. Jelastic-specific networking and internal IP references had to be identified and rebuilt for the new CloudStack IaaS environment, while application-to-database connectivity, background workers, scheduled jobs, and continuous tracking data had to be validated before traffic could safely move. This made the project a coordinated PaaS-to-IaaS application migration, rather than a simple cloud server migration.
A multi-node application may rely on platform-managed networking, internal addresses, environment variables, and service discovery. During a Jelastic migration, those dependencies must be identified and rebuilt correctly on the target infrastructure so application, database, and service nodes continue communicating after cutover.
Moving from a managed PaaS environment to CloudStack IaaS provides greater infrastructure control, but network boundaries, firewall rules, routing, and client isolation must be explicitly validated. For Reliva, that meant ensuring its migrated environment remained completely separated from every other customer managed under the same reseller account.
Application configurations tied to Jelastic’s internal networking or platform abstractions may no longer work once workloads move to a different cloud architecture. Connection strings, internal IP references, background services, and scheduled jobs therefore need to be reviewed and rebuilt as part of a proper PaaS-to-IaaS migration, rather than copied unchanged to the new environment.
Moving Reliva from Jelastic PaaS to CloudStack IaaS required more than transferring application files and databases. The platform consisted of multiple interconnected application, database, and service nodes, with dependencies that had developed around Jelastic’s networking and platform architecture. Before cutover, each dependency had to be identified, rebuilt, and validated against the new cloud environment.
Reliva’s application environment shared a reseller account with other customer workloads, but its infrastructure had to remain completely isolated. During the migration, network boundaries, routing, firewall rules, access controls, and service communication had to be recreated without exposing Reliva’s workloads to another customer—or allowing changes made for Reliva to affect anyone else.
For a multi-tenant cloud migration, preserving this isolation is just as important as migrating the application itself.
Several application configuration files and environment variables referenced Jelastic internal IP addresses directly. Those addresses would no longer exist after the workloads moved to CloudStack.
If even one outdated connection string remained, an application node could appear healthy while intermittently failing to reach the database or another internal service. We therefore had to identify and rebuild application-to-database connections, service endpoints, environment variables, and internal network references for the target infrastructure before production traffic moved.
Reliva continuously processes route planning, fleet coordination, and tracking data. Unlike migrating a static website or archive, this environment continued generating operational data throughout the migration window.
Scheduled jobs, queue workers, and background processes therefore had to be validated carefully around cutover. A failed job could create gaps in route history, while a duplicated worker could process the same data twice. Both situations might remain unnoticed until much later.
Maintaining data continuity during cloud migration meant validating not only whether the application loaded, but whether every background process was operating correctly after the move.
Because Reliva was managed under a reseller account containing other client environments, every migration task had to stay within Reliva’s own infrastructure boundary.
Provisioning changes, network configuration, maintenance activity, access controls, and account-level operations were reviewed specifically to ensure that no other hosted customer was affected by the migration.
This added an additional layer of operational control to what was already a complex multi-node PaaS-to-IaaS migration.
Move the Full Application Stack Together. Validate Every Dependency Before Cutover.
Reliva’s application, database, services, networking, scheduled jobs, and queue workers were migrated as one coordinated Jelastic PaaS to CloudStack IaaS migration, while keeping every change isolated from other customers on the reseller account.
We moved the application nodes, database tier, and supporting services together, preserving their dependencies and maintaining strict network isolation throughout the migration.
We replaced Jelastic-specific connection strings, environment variables, internal IPs, and service endpoints so application-to-database and node-to-node communication worked correctly on CloudStack.
Because Reliva continuously processes route, fleet, and tracking data, we explicitly validated scheduled jobs, background processes, and queue workers to prevent silent failures, duplicated processing, or gaps in historical data.
We scoped network, provisioning, access, and cutover changes only to Reliva, then verified that its CloudStack environment was healthy and every unrelated customer remained unaffected.
The result was a controlled multi-node PaaS-to-IaaS migration with preserved application continuity and customer isolation.
Reliva’s complete multi-node application, database, and services environment was successfully migrated from Jelastic PaaS to CloudStack IaaS while maintaining live route and tracking operations throughout the cutover.
Just as importantly, strict customer isolation was preserved — no other environment under the reseller account was affected, and scheduled jobs, queue workers, application connections, and database communication continued operating correctly after migration.
"AccuWeb.Cloud handled our multi-node logistics environment migration flawlessly with zero downtime and strict isolation preserved throughout."
Please ask your queries. We are available 24/7
Tell us about your application architecture, databases, services, networking, and dependencies. Our migration engineers will review your environment and prepare a migration plan designed to minimize downtime, preserve application continuity, and address platform-specific risks before cutover.
