Application Replatforming onto Managed Runtimes During Migration
Application replatforming moves an application onto a managed runtime during migration, such as Tomcat VMs to a managed app service or containers, with configuration changes only and no rewrite of business logic. NTSPL packages the app, externalises config, moves sessions and files to managed services, and cuts over with the same code on AWS, Azure or Google Cloud.
Delivered on
In scope
The Three Blockers That Decide Replatforming
Rehosting a web app onto a VM in cloud copies the patching, the Tomcat upgrade backlog and the 2 a.m. disk-full alerts. Replatforming fixes the runtime without touching the code. A typical candidate is a Java or .NET app on two or three VMs behind a hardware load balancer, with sessions in memory, uploads on a local disk and settings in an XML file edited by hand. Those three things decide whether the app can run on a managed runtime, and each can usually be solved with configuration.
NTSPL replatforms with a strict no-business-logic-change rule. We check the app against a short list of blockers: local file writes, in-memory sessions, OS-level dependencies, hard-coded hosts and scheduled tasks. Each is moved to a managed equivalent through config or a library swap. The app is built once into a deployable package or container image, tested on the target runtime, and cut over with the same release that runs on-prem today.
Applications That Gain Most from a Runtime Change
Signals you need Application Replatforming
- The app runs on Tomcat, JBoss, IIS, Node or PHP on 2-6 VMs that the team patches by hand.
- Runtime upgrades, such as Java 8 to 17 or PHP 7 to 8, are blocked by server ownership rather than code.
- Traffic varies more than 3x between peak and quiet hours, so fixed VMs sit idle.
- The database can move to a managed service of the same engine without code change.
When to choose something else
- If the app needs code changes to remove local state or fix scaling, see Application Refactoring.
- If the goal is breaking a monolith into services, that is a microservices programme under Application Modernization, not a migration-time change.
Packaging, State Externalisation and Runtime Setup
Blocker scan
Code and config are checked for local writes, in-memory sessions, OS calls, hard-coded hosts and cron jobs.
Packaging
The existing build is turned into a deployable package or container image with no source changes.
State externalisation
Sessions go to a managed cache, uploads to object or managed file storage, settings to environment variables or a secrets store.
Runtime and database setup
Managed runtime, autoscaling rules, managed database and private networking configured.
Pipeline handover
A basic build-and-deploy pipeline replaces manual WAR or zip copies.
Config-Only Replatform Pipeline
Config-Only Replatform Pipeline to Managed Runtime
A blocker scan decides the target runtime, then the existing build is packaged and state is pushed to managed services. The app is deployed unchanged and traffic is switched at the load balancer or DNS.
Select any component
Config-Only Replatform Pipeline to Managed Runtime: click any of its 7 components to see its role and the design choice NTSPL makes for it, or trace the 6-step primary path.
Managed Runtimes on AWS, Azure and Google Cloud
Java and PHP apps with no container skills fit Elastic Beanstalk; teams ready for images use ECS on Fargate with EFS for shared uploads.
IIS and Tomcat apps usually go to App Service with deployment slots for cutover; Container Apps suits apps already packaged as images.
Stateless HTTP apps in a container go to Cloud Run with minimum instances set to avoid cold starts at peak hours.
Runtime, State and Scaling Choices
App service or containers
Use a platform app service when the app is a standard Java, .NET, PHP or Node web app and the team has no container experience; it gives deployment slots and patching with the least change. Use containers when the app needs OS packages, a specific runtime build, or will later run alongside other services. Do not move a single small app to managed Kubernetes.
Where sessions go
Sticky sessions on a load balancer work but break autoscaling and zone failover. Move sessions to managed Redis through the framework's session provider, which for Tomcat, ASP.NET and PHP is a configuration change. Size the cache from peak concurrent users times average session size, with 2x headroom, and enable zone redundancy for production.
Handling local file writes
If the app writes uploads to a path, mount managed file storage at that path for a no-code fix. If it writes temporary files, use the instance's local disk and accept loss on restart. Logs should go to standard output, not files. Only where the app reads files across instances with locking does this become a refactor.
Scheduled jobs inside the app server
Cron jobs and Windows scheduled tasks often run on one specific VM. Replatforming means moving them to a managed scheduler that calls an endpoint or runs a job container. Ensure only one instance runs each job, since autoscaled instances would otherwise run it several times. List every job before cutover and test its timing.
Replatform Sequence from Blocker Scan to Cutover
Blocker scan and runtime choice
Code and config reviewed; target runtime and state services chosen.
Package and externalise state
Image or package built, sessions and files moved, config switched to environment variables.
Target environment and pipeline
Runtime, database and private networking built; pipeline deploys the current release.
Load and functional testing
Peak load replayed and user test cases run on the new runtime.
Cutover
Data synced, traffic switched by DNS or slot swap, old VMs held for rollback.
What you receive
Runtime Operations Measures After Replatforming
| KPI | Typical target |
|---|---|
| Business logic lines changed | Zero |
| Deployment time per release | Under 15 minutes from pipeline |
| OS patching effort for the app | Removed for app-service targets |
| Off-peak instance count | Scaled to minimum of 2 |
Where Config-Only Changes Turn into Code Changes
| Risk | How NTSPL prevents it |
|---|---|
| A hidden OS dependency, such as a font, native library or COM component, breaks on the new runtime. | The blocker scan includes a process and library trace on the running VM; containers are used where OS packages are needed. |
| Scheduled jobs run once per instance after autoscaling. | Jobs move to a managed scheduler with single-execution control before go-live. |
| Cold starts slow the first requests after quiet periods. | Minimum instances are set for production and warm-up endpoints configured. |
Replatform or rehost a web application during migration?
Rehost when you have hundreds of servers to move by a deadline, the app is due for retirement within two years, or the vendor supports it only on a VM. Replatform when the app is in-house or open-stack, will live five years or more, and passes the blocker scan with config-only fixes. Replatforming typically adds 3-5 weeks per app but removes OS patching, enables autoscaling and gives a deployment pipeline. For a mid-size estate, replatforming the 10-20% of apps with the highest change rate is usually the best use of the effort.
Key facts: Application Replatforming
Application Replatforming in Practice
2 Application Replatforming scenarios, from Television broadcasting and Flexible packaging manufacturing, plus related platform case studies.
Broadcaster replatforms its ad-scheduling app to Cloud Run with no code changes
Packaging company moves its artwork approval portal from VMs to ECS on Fargate
Real-estate developer handles 40x launch-day traffic on its booking portal
Logistics SaaS scales shipment tracking to 9 crore events a day on EKS with Karpenter
Application Replatforming: Frequently Asked Questions
Does replatforming require code changes?
Not to business logic. We change configuration, swap session and storage providers through framework settings, and package the existing build. If a fix needs code changes, such as removing file locking across instances, we flag it and move the app to refactoring instead.
How long does replatforming one application take?
Typically 4-6 weeks for a standard Java, .NET or PHP web app, including load testing and cutover. Apps with many scheduled jobs or native libraries take longer. Several apps can run in parallel once the first has set the pattern.
What does replatforming cost?
For a single web app with a database, services usually range from INR 4-10 lakh. Run cost is often lower than VMs because instances scale down off-peak and OS licences are included in the platform price. We compare against the rehost run cost in the plan.
Can a .NET Framework app be replatformed?
Yes. .NET Framework 4.x apps on IIS can run on Azure App Service for Windows or in Windows containers. Moving to modern .NET is a code change and belongs in refactoring or modernization. We check COM components, GAC assemblies and registry use first, since those decide between App Service and Windows containers.
Are managed runtimes available in Indian regions?
Yes. App Service and Container Apps run in Central India, Elastic Beanstalk and ECS run in Mumbai and Hyderabad, and Cloud Run runs in Mumbai and Delhi. Keeping the runtime, cache and database in the same Indian region keeps latency low and simplifies DPDP Act 2023 records.
Who maintains the app after replatforming?
Your team keeps ownership of the code. The platform handles OS and runtime patching for app-service targets; for containers, base images still need updating, which the pipeline can automate. We hand over the pipeline, runbooks and alerts. Your team can run the first two releases with us before taking over alone.