Platform Transition & Migration
Is this still the right foundation for what comes next?
Transition is a decision with a cost, a risk profile and an opportunity cost. Lornets is paid to establish the right decision, including when the right decision is not to migrate.
The commercial position
- The situation
- A rebuild, cloud move, backend replacement or platform change is being proposed, and the organisation needs evidence before committing.
- The decision
- Is the current foundation still the right place to operate, and what, if anything, should move?
- What Lornets does
- We establish the constraint first, then compare Stay, Refactor, Hybrid and Migrate against cost of change, cost of staying, expected benefit, transition risk, data transition, verification and decommissioning.
- What you leave with
- The constraint, stated in technical and commercial terms
- Transition options assessed as alternatives
- A recommended decision with the evidence behind it
- Where transition is justified, a sequenced plan with verification and decommissioning
- What may happen next
- Where migration is justified, Lornets can implement it. Where it is not, the work usually returns to hardening or to no change at all.
- When this is not appropriate
- The migration is already decided and only delivery capacity is required
- The system carries no meaningful commercial or operational consequence
- You want confirmation that a particular architecture or platform is inherently better
Stay, Refactor, Hybrid or Migrate
The engagement resolves to one of four positions, established against the target operating state and the available evidence.
Stay where it works. Strengthen what matters. Move only what the evidence justifies.
Four possible outcomes
- 01
Stay
The current foundation can support the target operating state.
- 02
Refactor
The foundation remains viable but requires meaningful restructuring.
- 03
Hybrid
Preserve significant working parts while selectively replacing or externalising constrained components.
- 04
Migrate
The existing foundation creates a material constraint that cannot reasonably be addressed through proportionate improvement.
Where this sits next to Production Hardening & Scale
Where the conclusion is Stay or a targeted Refactor, implementation moves naturally into Production Hardening & Scale. Where the conclusion is Hybrid or Migrate, a controlled transition programme is defined here.
- Production Hardening & Scale
- How do we strengthen and scale the foundation we intend to keep?
- Platform Transition & Migration
- Is the existing foundation still the right place to operate, and if not, what should move?
Production Boundary Map
Instead of treating an application as something that must either stay entirely where it is or be completely replaced, Lornets establishes where production responsibility should sit across the system.
A full-platform decision is often too crude. The correct answer may be to keep most of the existing system while moving responsibility for only the components that genuinely require greater control.
Each relevant area resolves to Keep, Strengthen, Externalise, Replace
- User interface
- Application logic
- Authentication
- Authorisation
- Core APIs
- Data
- Background processing
- AI orchestration
- Infrastructure
- Observability
- Delivery
The constraint has to be demonstrated
Before recommending structural change, Lornets establishes what the system supports today, what it must support next, what actually prevents that and what happens if nothing changes.
A general statement that the system needs to scale is not sufficient justification for platform replacement.
What is established
- Current and target operating context
- What the system supports today, and what it must support next.
- Demonstrated constraint
- What prevents that, and the evidence behind it.
- Consequence and timing
- What happens if nothing changes, and when it becomes material.
- Existing-platform options
- Whether the constraint can still be addressed proportionately without migration.
What a transition recommendation has to answer
Where transition is genuinely being considered, the recommendation has to survive a defensible set of questions before anyone commits budget to it.
The more expensive and disruptive the recommendation, the stronger the evidence required to justify it.
- 01Why change, and why now?
- 02What demonstrated constraint does the transition solve?
- 03What alternatives were considered, and why are less disruptive options insufficient?
- 04What must the target state support, and what new complexity or dependency does it introduce?
- 05What is the expected cost of transition against the cost of staying?
- 06What transition risks are introduced, and how will success be verified?
Define the operating requirement before choosing the technology.
Target architecture follows the target operating state. It does not begin with a predetermined runtime, cloud provider, orchestration platform, message broker or database.
Target characteristics established first
- Availability and recovery
- Latency, throughput and concurrency
- Data volume and geography
- Tenant model and security
- Deployment and team ownership
- Cost envelope
- AI workload where relevant
The economics of the decision
A transition is a business and engineering decision, not only a technical one.
Where reliable evidence is unavailable, the uncertainty is stated explicitly; no precise return projection is invented.
Cost of change
- Engineering, testing and data transition
- Parallel running and infrastructure
- Training and operational transition
- Lost product-delivery capacity
Cost of staying
- Rising infrastructure and operational burden
- Engineering slowdown and recurring incidents
- Customer limitations and manual workarounds
- Specialist dependence and vendor pricing exposure
Expected benefit
- Capacity and reliability
- Engineering velocity
- Reduced dependency and operational burden
- Customer capability or cost improvement
When transition is justified
Where the decision engagement shows that substantial change is warranted, the transition is engineered as a controlled programme. The engineering discipline below applies in proportion to the risk of the move.
A migration is not successful merely because functionality moved. Functional parity alone is not sufficient evidence of a successful transition.
Proof the target works
Where a decision rests on an unproven assumption, a bounded technical experiment reduces the uncertainty before a major commitment. This is used where the uncertainty is material, not for every decision. A before-state baseline is established where possible, covering latency and throughput, failure rates and recovery, deployment behaviour, infrastructure and operating cost, operational effort, ai quality and cost where relevant, so the new state can be compared against the same characteristics.
Data integrity where data moves
Data migration is not complete because an import process finishes. The resulting data state must be verified.
- Source and target mapping, with any transformations
- Integrity checks and reconciliation
- Sequencing, dual-write risk and cutover
- Backup, security and recovery
Transition strategy and reversibility
No technique is universally superior. Selection depends on coupling, risk, data consistency, operating requirements, timeline, reversibility. Each step also carries an explicit position on what can be restored, whether the move is reversible, recoverable through a defined procedure or effectively irreversible, and that position informs cutover planning.
- Big-bang transition
- Phased transition
- Parallel running
- Incremental transition
Risk and staged cutover
Transition risk is tracked separately from the underlying production risk, because moving between states creates exposure that neither state carries on its own. A large transition should not become one irreversible programme, so decision points are applied in proportion to the risk: constraint demonstrated and target approach supported, high-risk assumptions tested where the uncertainty is material, transition readiness established, cutover decision, decommissioning approval.
Verification and decommissioning
Verification covers both functional behaviour and the production characteristics the target state has to meet: performance, reliability, security, recoverability, observability, operational effort and cost. Decommissioning follows adequate verification of the new state, never precedes it.
- Retiring superseded services and infrastructure
- Revoking credentials and obsolete access
- Retaining required data
- Updating integrations, monitoring and documentation
- Ending unnecessary licences
Two commercial stages
Stage 1
Platform Transition Decision
An independent decision engagement establishing whether the current foundation is still the right place to operate.
From £7,500
Final scope depends on system complexity and the depth of evidence required.
Outputs
- The demonstrated constraint and the evidence behind it
- Current-state baseline and target operating state
- Production Boundary Map
- Stay, Refactor, Hybrid or Migrate recommendation
- Cost of change, cost of staying and expected benefit
- Transition risks and an indicative roadmap
Stage 2
When transition is justified
Engineering the transition, undertaken only where the decision engagement shows that substantial change is warranted.
Scoped separately
Transition work varies substantially in cost and duration, so Lornets does not publish package tiers or an artificial maximum.
Outputs
- A staged transition programme with proportionate decision points
- Data transition and verification where data moves
- Functional and production verification against the baseline
- Decommissioning of the superseded state
The decision engagement remains valuable even when the answer is Stay.
The value of Stage 1 is the decision itself, including a decision to Stay. The recommendation follows the technical and commercial evidence.
Common questions
- Do we need to move away from Lovable, Replit, Supabase or another rapid-development platform?
- Not because of the platform name itself. Platform choice is an input to the assessment, not the verdict. Migration is recommended only where the current foundation materially constrains what the organisation now requires and the expected benefit justifies the cost and risk of transition.
- When is migration actually justified?
- When the evidence shows a material constraint in the current foundation that conflicts with the required operating state, and changing the foundation is preferable to staying or hardening in place. We weigh the cost of change, the cost of staying, the expected benefit and the transition risk as reasoned judgements rather than presenting them as a score.
- Do you always recommend microservices?
- No. Architecture is not a maturity ladder. Microservices introduce their own operational, deployment, observability and coordination requirements, which can add cost without addressing the demonstrated constraint. The appropriate architecture depends on the constraints and the operating context.
- Can the answer be a hybrid architecture?
- Yes. A partial transition is often the appropriate end state. Some components remain where they are while specific boundaries move or are externalised. Hybrid is a legitimate technical decision, not a failed migration.
- How do you compare staying with migrating?
- By comparing the current system against the required operating state, then examining the cost of staying, the cost of change, the expected benefit, the transition risk and the new operational obligations the target architecture would create. The more disruptive and expensive the recommendation, the stronger the evidence required to justify it.
- What happens to our data during a migration?
- Data transition is treated as a technical workstream in its own right, not as a side effect of moving application code. Depending on scope it may include data mapping, integrity checks, migration sequencing, backfill, cutover, rollback or recovery planning, and validation after transition.
- What happens to the old system?
- Decommissioning is part of the work and follows adequate verification of the new state. It may include retiring services and infrastructure, revoking credentials and access, retaining required data, updating integrations, monitoring and documentation, and ending unnecessary licences.