Cloud and Kubernetes migration

Cloud and Kubernetes migration with a rollback plan

We move your systems to AWS, Azure or Google Cloud in stages, with criteria to sign off each step and a rollback plan written before we start. It is a cloud and Kubernetes migration designed so you can stop and go back without drama.

This page covers migration, one of the four services in Cloud: design and migration, which also covers architecture and landing zone, initial deployment and Kubernetes.

Tell us about your caseBook a 30-minute call

A first conversation to understand your case. Then a tailored written proposal, with the scope made clear, before we start.

AS IT IS TODAYTARGET ARCHITECTUREROLLBACKCONCEPTUAL EXAMPLE

01 · When

When migrating makes sense (and when it does not)

It fits if

  • You have to change platform and cannot improvise on the day of the change.
  • Your project is bounded: a small number of applications, in stages and to a single cloud destination.
  • You can name a person on your side to give the go-ahead for each step into production.

Better another option if

  • You want to rewrite your application, or you need a mass data-centre migration, SAP or mainframe.
  • You need a migration with no downtime at all or round-the-clock operations afterwards, which this service does not cover.

Signs your platform needs a change

  • What you have works and touching it is scary, because nobody remembers well what each piece depends on.
  • Your hosting or data centre contract is ending and the time to decide is running out.
  • You want to switch cloud or move to containers, but you do not know where to start or what risk you take on.
  • You started a migration and it stalled halfway, with part of the systems in each place.

02 · Scope

What a staged migration includes

  • We take an inventory of your systems and map their dependencies, with an owner for each piece.
  • For each application we decide whether to move it, adjust it, replace it, retire it or leave it as it is (assessment).
  • We migrate from a hosting provider, a VPS or a data centre to AWS, Azure or Google Cloud, or between those clouds.
  • We move to managed Kubernetes (EKS, AKS or GKE) only when it pays off; we do not operate a cluster of our own without an agreement.
  • We coordinate the technical side with your current provider, such as exporting data or changing DNS, when you authorise us in writing.

The seven phases

  1. Assessment: what you have, what each piece depends on and what is best to do with it (assessment), with the scope agreed in writing.
  2. Prepare the destination: accounts, identity and permissions, network, activity logging, basic security policies and cost control (landing zone). It is the governance base of the destination and is ready before anything is moved.
  3. Move in batches, starting with something small but representative so we can learn (waves).
  4. Validation: we test before the real change, with “it went well” criteria agreed in advance.
  5. The real change: an agreed window, a person on your side who decides and, where applicable, gradual traffic shift (cutover). In some cases replicating the data allows a short window, but we do not promise it.
  6. The way back: which signal forces a return, who decides, how it is done and from which point it is no longer possible (rollback). We separate application and data, because reverting data is the hard part, and we rehearse it where feasible.
  7. Stabilise and hand over: we do not switch off the previous environment on the same day, and we check that your team knows how to deploy, revert and restore.

What you get from the migration

  • An inventory of your systems and a map of their dependencies, with an owner for each piece.
  • A reasoned decision for each application and a staged plan with owners and dependencies.
  • Acceptance criteria and a checklist that is reviewed before each change.
  • A documented rollback plan, with its point of no return marked in advance.
  • Infrastructure as code in your accounts, if it is in scope, plus documentation and handover to your team.

03 · Rollback

Rollback plan and point of no return

It is the documented procedure for returning to the previous state if a stage fails. It states what is reverted, who decides and until when it is possible. We mark the point of no return in advance, after which going back is no longer viable.

  • The way back: which signal forces a return, who decides, how it is done and from which point it is no longer possible (rollback). We separate application and data, because reverting data is the hard part, and we rehearse it where feasible.
  • A documented rollback plan, with its point of no return marked in advance.
  • A written rollback plan before the change, up to the agreed point of no return

04 · Sources

Sources we migrate: VPS, hosting, data centre or between clouds

  • VPS
  • Hosting
  • Data centre
  • Between clouds
  • We migrate from a hosting provider, a VPS or a data centre to AWS, Azure or Google Cloud, or between those clouds.
  • Yes. We start from an inventory with a dependency map and decide per application whether to move it as is, adapt it or leave it. Mass data-centre, SAP or mainframe migrations are out of scope, and we say so from the start.
  • We coordinate the technical side with your current provider, such as exporting data or changing DNS, when you authorise us in writing.

05 · Kubernetes

Does Kubernetes pay off?

When you have several services, frequent releases and a team able to operate it. If your application is simple, managed containers or a PaaS service may be more reasonable. We look at the number of services and release frequency. We assess it with you and do not recommend Kubernetes by default.

  • We move to managed Kubernetes (EKS, AKS or GKE) only when it pays off; we do not operate a cluster of our own without an agreement.

Why Kubernetes should not give you headaches

06 · Limits

What falls outside

  • We do not rewrite your application: a deep refactor is treated as a separate project.
  • We do not promise zero interruptions: if there is downtime, it is agreed in the plan for each system.
  • Data that requires strict consistency with no downtime window is assessed case by case and is not promised.
  • It does not include mass data-centre migrations, SAP or mainframe, or changes demanded by a closed-source software vendor.
  • It does not include round-the-clock operations after migrating, or certifications or regulatory compliance.
  • We do not negotiate contracts with your providers; we do coordinate the technical side with them if you authorise us in writing.
  • Changes in production are made with your prior written authorisation (an email or a ticket from your responsible person is enough) and within the agreed window. A person on your side gives the go-ahead.

How we charge for the migration

  • Everything is quoted to fit your case: you receive the scope and the quote in writing before we start.
  • The plan is your property, and you decide who carries out the migration.
  • If there is an execution phase, it is quoted in writing, with the scope made clear, before we start; with the plan you decide whether to migrate, how and in what order.
  • Cloud provider and licence costs, including the period of double cost between source and destination, are yours to bear.

07 · Afterwards

After migrating: handover or operations

Your team, using the documentation and step-by-step guides we deliver at handover. If you prefer not to take on operations, DevOps as a Service in defined hours and agreed schedule can be arranged as a separate service. None of this requires you to carry on with us.

Who works with you

We work in cloud and DevOps, headquartered in Las Palmas de Gran Canaria with a team spread across Spain. We work remotely with B2B startups across Spain.

“We engaged Nubyron’s services and the experience has been very positive. The technical support is efficient and responds quickly to any request. They supported us throughout the application deployment process within Nexure.ai, showing great dedication and professionalism. We are very satisfied with the team’s work and the results obtained.”

Alexis PifanoClient · application deployment in productionApplication Deployment · Nexure.ai

“If a company needs specialized Kubernetes expertise, I would strongly recommend speaking with the Nubyron team. Their value proposition is solid and especially distinctive because of how they work.”

Pedro RodríguezProfessional recommendation · Kubernetes specialistCloud & Kubernetes Specialist · Plataformas Cloud

08 · FAQ

Cloud migration FAQ

How do you migrate to the cloud without stopping the business?

You assess before moving anything, decide what to do with each application, migrate in stages with acceptance criteria, and keep the rollback available up to a point of no return marked in advance. If there will be downtime, it is agreed in the plan, system by system.

What is a rollback plan in a cloud migration?

It is the documented procedure for returning to the previous state if a stage fails. It states what is reverted, who decides and until when it is possible. We mark the point of no return in advance, after which going back is no longer viable.

When does migrating to Kubernetes pay off?

When you have several services, frequent releases and a team able to operate it. If your application is simple, managed containers or a PaaS service may be more reasonable. We look at the number of services and release frequency. We assess it with you and do not recommend Kubernetes by default.

Can you migrate from a VPS, hosting provider or data centre to AWS, Azure or Google Cloud?

Yes. We start from an inventory with a dependency map and decide per application whether to move it as is, adapt it or leave it. Mass data-centre, SAP or mainframe migrations are out of scope, and we say so from the start.

Who runs the environment once the migration is finished?

Your team, using the documentation and step-by-step guides we deliver at handover. If you prefer not to take on operations, DevOps as a Service in defined hours and agreed schedule can be arranged as a separate service. None of this requires you to carry on with us.

How long does a migration take?

It depends on the number of systems and their dependencies, so we give you the timeline in writing after the assessment. We do not give generic timelines before knowing your inventory, because a figure without that analysis would not be reliable. We confirm it in writing.

Do you migrate to AWS, Azure and Google Cloud?

Yes: we work with AWS, Azure and Google Cloud, with a single cloud destination per project. We recommend the destination that best fits your application, your team and your current contract, and the decisions are documented in your company’s accounts.

First step

Tell us about your case

We start with an assessment, not a sale. Tell us about your environment and what you want to solve, in a minute. We reply with next steps and, if it is a fit, a written proposal.

Prefer to talk for 30 minutes?

To get started, we only need your contact details and a short description.

What are you interested in?

Please use your company email.

Tell us about your environment and what you want to solve (at least 15 characters). With the FinOps audit you can leave it empty. Do not include credentials, third-party personal data or confidential client information.

Do not include passwords, access keys, tokens or credentials in this form. We never ask for them here. Read-only access is set up later, with your IT team.

Add more context (optional)

Quevedo Tech Group, S.L. will process your data to assess your request and prepare a proposal (Art. 6(1)(b) GDPR). Providers: email, anti-spam and CRM (Odoo). Your data will not be used for advertising. Rights and more information: rgpd@nubyron.com and Data protection information.