Legacy application migration services
Legacy application migration is the process of moving a working web or mobile app to a supportable platform while protecting the users, data and workflows it serves. We help you choose what to retain, what to replace and how to release the change safely.
You need a better foundation for a system you cannot switch off
The application may run operations, serve customers or hold records your team depends on. At the same time, unsupported dependencies, fragile code or slow releases may make every change harder. You need to know whether moving it is worth the investment and how to avoid disrupting work in progress.
We start with the business decisions: what must still work, which risks are growing, and what new capability would make the move worthwhile. Those answers determine whether a focused upgrade, a back-end migration or a wider rebuild makes sense.
Why revisit the migration decision now?
A support deadline can start the conversation. The decision should also account for the rest of your stack and the value the application still creates.
A framework's support window is closing
Yii2 shows why timing matters. Yii's release cycle lists 23 November 2027 as end of life for Yii 2.0.50 and later; Yii 2.0.49 and earlier has a listed end-of-life date of 23 November 2026. From 23 November 2026, the 2.0.50+ branch is scheduled for security fixes only.
We check the installed version, PHP runtime and extensions before advising whether an upgrade, a migration to Yii3 or a move to another framework is appropriate. A date is a reason to plan, not proof that every Yii2 system must be rewritten.
The rest of your stack has its own clock
The Symfony release calendar lists security fixes for Symfony 6.4 until November 2027. PHP's support table lists 31 December 2026 for PHP 8.2 security support, while Node.js lists 30 April 2027 as the planned end of life for Node.js 22.
Framework, runtime, integrations and hosting may have different constraints. We review them together. Sometimes a contained upgrade is enough; deeper migration makes sense when the application itself also needs a more maintainable home.
The commercial case may have changed
AI-assisted tools can help engineers explore unfamiliar code, prepare repetitive changes and accelerate parts of test creation. Our developers review the output against business rules, security, data and actual user behaviour. Results vary with code quality and access, so we estimate from evidence rather than promise a cheap rewrite.
We compare the cost of migration with the cost of staying put: support exposure, slower delivery and improvements you have postponed. A phased scope can preserve valuable functionality now and defer redesign that does not earn its place.
What could your application move from and to?
Illustrative routes, not automatic rewrites. We check the existing system and its users before deciding whether to upgrade, replace a layer or move platforms.
| Starting point | Possible destination | What to assess |
|---|---|---|
| Yii2 business application | Laravel or Python (Django/FastAPI); sometimes Yii3 | Extensions, business rules, PHP version, authentication and API parity. |
| Yii2 website or content-led portal | Payload + Next.js; Laravel for complex logic | Content, editor permissions, forms, redirects and SEO. |
| Bespoke PHP or older Laravel | Current Laravel; Python where warranted | Dependencies, hidden rules, tests and upgrade feasibility. |
| Drupal 7 with custom workflows | Payload + Next.js; Laravel/Python for bespoke workflows | Content model, modules, editors and URL mapping. |
| Plugin-heavy WordPress portal | Payload + Next.js, or Laravel/Python | Plugin logic, editing, integrations, members and SEO. |
| AngularJS or Vue 2 interface | React/Next.js with TypeScript; supported framework upgrade | Journeys, accessibility, state and API continuity. |
| Older Node.js / JavaScript back end | Supported Node.js/TypeScript; Laravel or Python | Package support, jobs, data and integrations. |
| Legacy Xamarin, Cordova or Ionic app | React Native with Expo; native iOS/Android where warranted | Device features, offline use, notifications and store continuity. |
| Older React Native or native mobile app | Supported React Native with Expo, or updated native code | Native modules, UX, performance, OS support and shared-code value. |
Explore the technologies behind a migration
The right destination depends on your content, business rules and device needs. Explore the technologies we work with before deciding what fits your application.
What needs to change, and what should stay?
Three common routes. We recommend the smallest sound change that addresses the risk and opens up the next stage of the product.
Improve the current codebase
Keep the framework where support and architecture allow it. Update dependencies, structure and tests so future changes are less fragile.
Replace the back end first
Keep the front end familiar while moving business logic and APIs. Test the contracts users and integrations depend on before switching over.
Move the whole application
Migrate front end and back end, with selective redesign where it adds value. Phase the work by workflow, module or user group where feasible.
Can people keep using it while the engine changes?
Usually, the existing application continues to run while we build and verify the replacement. We map critical journeys, permissions, reports, notifications and API behaviour before changing what serves users. If the current system has little test coverage, we may first establish independent behaviour, contract and integration checks; where practical, we exercise the same scenarios against both versions.
That evidence sits alongside human acceptance, staged releases, monitoring and a rollback plan appropriate to the system. We will flag old behaviour that should be preserved and defects that should not be copied.
What happens to the data and integrations?
Legacy tables can hide duplicate identities, inconsistent statuses and exceptions that code alone does not reveal. We map these realities, agree which structures remain and which should improve, then check the results before and after a move.
A back-end migration may initially keep the database in place. If the data model limits reporting or future integration, we can make its redesign a separate, visible workstream. We also plan how connected services continue to receive the data they expect.
From assessment to a controlled release
From uncertainty to a controlled release
Agree the business outcome, evidence and decision point for each stage. The detail depends on access, dependencies and how the application is used.
Assess the current system
Review source code, framework and runtime versions, infrastructure, licences, mobile SDKs where relevant, integrations, data, security and business-critical workflows. Identify unknowns and recommend whether migration makes commercial sense.
Define the destination and boundaries
Choose the target architecture for the requirements, such as Payload with Next.js, Laravel, a Python back end, or React Native with Expo or native development for mobile. Agree what remains, what changes and the tests and acceptance criteria.
Protect behaviour and prepare data
Establish a baseline for essential journeys and API contracts. Map records, identifiers and edge cases; create migration and reconciliation checks before a production cutover.
Build, compare and release in stages
Implement the agreed scope, review the work, run automated and human checks, trial releases where feasible, then monitor and support the cutover with a proportionate rollback plan.
A live Yii2-to-Python migration: Image Approvals
We migrated the Image Approvals platform's Yii2 back end to Python. The product supports image approvals for film and television productions, so the application and the business workflow mattered throughout the change.
The Image Approvals case study shows the delivered product. Its imagery here is genuine product imagery, rather than a mock-up of the migration. The lesson for any migration is to preserve the workflows that create value while making deliberate choices about the technology underneath.
Find out whether a migration earns its cost
The App Rescue Assessment examines the code and the risks before a larger commitment. From there, we can scope the recommended route, stages and indicative investment, including a smaller intervention if that makes more sense.
Questions before you commit
Usually the existing application continues to run while the new parts are built and tested. The final cutover may require a short maintenance window or carefully managed data synchronisation. We assess those constraints early and agree the release plan with you.
Yes, where the front end and API contracts can be retained safely. We map the existing endpoints, authentication, permissions and data formats, then test the new back end against the agreed behaviour. Some contracts should be improved, but that is a deliberate scope decision.
We assess web applications built on Yii2, bespoke PHP, older Laravel, Drupal 7, plugin-heavy WordPress, AngularJS, Vue 2 and older Node.js/JavaScript stacks, as well as mobile apps built with Xamarin, Cordova, Ionic, React Native or native iOS/Android code. A content-led website may move to Payload CMS with Next.js. A portal with complex business rules may need a Laravel or Python back end, while a dated mobile app may move to React Native with Expo or updated native development.
For example, a Yii2 operations portal may move to Laravel or Python, while a Yii2 content website may be a better fit for Payload. A Drupal 7 or plugin-heavy WordPress portal may move to Payload with Next.js if content and editorial control are central, or to a Laravel/Python app if bespoke workflows dominate. You can also keep a working front end and replace only its back end. Mobile apps need a separate decision about shared code, device features and app-store continuity.
Drupal 7, AngularJS, Vue 2 and Xamarin have reached official end of life. WordPress remains actively supported, so leaving it is often a question of fit or plugin complexity. An older Laravel, Node.js, React Native or native app may only need an upgrade. We recommend a route after checking the exact versions, integrations, data, users and commercial case.
Yes, when a shared iOS and Android codebase fits the product. We assess the existing app's APIs, user data, push notifications, offline behaviour, device integrations, accessibility and app-store identifiers before choosing the approach. Expo can support custom native code through development builds, but some apps will still benefit from maintaining or modernising native Swift/Kotlin code. We plan how existing users receive the replacement and test releases on real devices.
No. We review the codebase, content and editorial needs, integrations, team skills, mobile features and roadmap before recommending a destination. That might be Payload with Next.js for a content-led website, Laravel or Python for a web app, React Native with Expo for a mobile app, or native iOS/Android development. An upgrade within the existing stack may be the better answer.
We establish a baseline of critical user journeys, business rules, permissions, reports and API behaviour. We use automated tests and human acceptance checks, compare key outputs and reconcile migrated data. Existing test gaps can be addressed before migration, although no test suite alone proves every behaviour.
Yes, but it helps to separate essential migration from optional redesign. We identify data and UX changes that materially improve the product, estimate them openly, and choose a phased release or combined scope according to risk and value.
AI can reduce some repetitive engineering and analysis effort when engineers guide and verify it. Legacy business rules, poor documentation, data anomalies, integrations and release risk still require careful human work. We assess your codebase before estimating the effort and expected benefit.
The official Yii release-cycle table lists an earlier end-of-life date for Yii 2.0.49 and older than it does for 2.0.50 and later. We check the precise framework, PHP version, extensions and support arrangements during assessment and prioritise security measures accordingly.
The range depends on application size, business rules, tests, integrations, data quality, the amount of redesign and how easily the system can be released in stages. The App Rescue Assessment creates a fact base; we then scope and cost the recommended route before a larger delivery commitment.
Application modernisation can mean improving the existing product in place: refreshing UX, upgrading packages, adding tests or refactoring a component. Legacy application migration means moving code, data or functionality to a different platform. Sometimes the best project does both, for example replacing an unsupported back end while redesigning a dated interface. We assess the commercial case and choose the scope together.
Migration routes by existing platform
Each platform has different risks. Start with the technology you have, then use the wider service to compare a partial replacement with a full move.
Yii2 application migration
Assess versions, extensions, business rules and a route to Laravel, Python or another suitable stack.
Learn moreMODX website migration
Move content, templates and editor workflows to a platform that suits the site's future.
Learn moreDrupal 7 migration
Protect content, custom modules, URLs and search visibility in a planned transition.
Learn moreAngularJS migration
Replace an unsupported interface while preserving APIs and important user journeys.
Learn moreNeed help building your ideas?
Tell us where you're headed and we'll come back with our thoughts, a realistic plan and a rough cost estimate. Scorchsoft is a UK-based team of app, portal and AI developers, working in-house from Birmingham's Jewellery Quarter.