Cloud: architecture and migration

Your cloud grew without a plan. We put it in order in stages.

We review how your cloud is built, propose a plan and carry it out in stages, with the rollback and the point of no return agreed beforehand. We work in your accounts, in your company’s name, and document everything. Containers and Kubernetes only if they pay off.

Cloud architecture and landing zone on AWS, Azure or Google Cloud, for startups and product teams.

Tell us about your caseBook a 30-minute call

A first conversation to understand your case. Then a tailored written proposal before we start.

AS IT IS TODAYTARGET ARCHITECTUREROLLBACKCONCEPTUAL EXAMPLE

01 · Who it is for

Who it is for (and who it is not)

It fits if

  • You run a product or systems in the cloud, or are about to, and have no dedicated platform team.
  • You need a project with a start and an end: designing, deploying or migrating the platform, with a closed deliverable.
  • You want to decide with your platform in front of you, with the decisions documented and everything in your company’s accounts.

Better another option if

  • You want to develop or rewrite your application: this service works on the infrastructure.
  • You need ongoing operation after the project: that is DevOps as a Service, during agreed hours and quoted separately.
  • Your case is a mass data-centre, SAP or mainframe migration, which we will tell you about from the start.

Signs you need to redesign your platform

A badly framed cloud project is paid for later: ungoverned accounts, releases that cannot be repeated and migrations left half-done. This may sound familiar if:

  • Your hosting or data centre contract is ending and the time to decide is running out.
  • Your cloud accounts grew without a plan: a single account, broad permissions and an undefined network.
  • You deploy by hand or on a loose server, and only one person knows how.
  • What you have works and touching it is scary, because nobody remembers what each piece depends on.
  • You have a Kubernetes cluster that has not been upgraded, or you wonder whether Kubernetes is worth it.

02 · Foundation

Architecture and landing zone

We put the foundation of your cloud account in order before building on it: identity, network, accounts and costs.

  • Architecture document with a diagram and justified decisions.
  • Landing zone: accounts or subscriptions, identity and permissions, network and activity logging.
  • Basic cost budgets and alerts.
  • Infrastructure as code (IaC) and a usage guide.

Not included: A formal security or compliance audit (ISO 27001, ENS), ongoing operation and workload migration.

03 · Deployment

Initial deployment and infrastructure

We turn a manual deployment into a repeatable one, with environments described as code and a way back where technically possible.

  • Development, staging and production environments described as code.
  • A basic deployment pipeline and secrets kept out of the code.
  • Deployment strategy and, where technically possible, a rollback strategy.
  • Deployment guide (runbook) and handover.

Not included: Development of your application and ongoing operation. Later evolution and maintenance of the pipeline belong to DevOps as a Service.

04 · Migration

Staged migration with a way back

We move applications from a hosting provider, a VPS, a data centre or between clouds, in stages and with the rollback in writing up to the agreed point of no return. This is the summary; the detail is on the migration page.

  • Inventory and dependency map, with a reasoned decision per application.
  • Staged plan with acceptance criteria.
  • Rollback plan with the point of no return marked in advance.
  • Staged execution and a closing report.

Not included: Mass data-centre migrations, SAP or mainframe, rewriting applications, negotiating contracts with your current provider, and ensuring there is no downtime: it is agreed in the plan, system by system.

Cloud migration with a rollback plan

05 · Kubernetes

Kubernetes: adoption and upgrades

We decide with you whether Kubernetes pays off and, if so, we adopt it, move workloads or upgrade versions, with a way back where technically possible.

  • Assessment of whether Kubernetes pays off, with alternatives (managed containers, PaaS).
  • Design of a managed cluster (EKS, AKS or GKE) with IaC and GitOps.
  • Plan and execution of a version upgrade, with rollback where technically possible.
  • Documentation and handover to your team.

Not included: Running the cluster on an ongoing basis (that is DevOps as a Service, within the agreed scope and hours), self-managed clusters without an agreement, and bespoke internal platforms.

06 · Method

How we work and what you receive

  1. Tell us what you need. A first conversation to understand your case.
  2. A tailored written proposal, with scope, deliverables, phases and budget, before we start.
  3. We work in phases in your accounts and repositories. 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.
  4. We close with documentation, step-by-step guides and a handover. Your team runs it, or you can ask us for a DevOps as a Service proposal.

How we do it, in writing

  • Every project starts with a written scope: objective, deliverables, phases and acceptance criteria.
  • Important decisions are documented, with the alternatives we ruled out and why.
  • Infrastructure is described as code in your repositories; the state and the deployment credentials live in your accounts.
  • Every risky change has its rollback plan written before it is carried out, up to the agreed point of no return.
  • When we finish you receive documentation, step-by-step guides and a handover to your team.

What you receive

  • Design, build and migration on AWS, Azure or Google Cloud, with a single cloud destination per project.
  • Infrastructure as code and documentation in your repositories and accounts.
  • Basic cost control in the design (tagging, budgets and alerts).
  • Handover to your team.

How it is engaged

  • Everything is quoted to fit your case: you receive the scope and the quote in writing before we start. We do not publish rates.
  • If the scope changes, the change, its cost and its timeline are agreed in writing before they are applied.
  • Cloud provider and licence costs, including the period of double cost between source and destination, are yours to bear.
  • The plan, the code and the documentation are yours; you decide who carries out each phase.

What is not included

  • Developing or rewriting your application.
  • Ongoing operation after the project (that is DevOps as a Service, during agreed hours and quoted separately).
  • Promising that there will be no downtime: it is agreed in the plan, system by system.
  • Mass data-centre migrations, SAP or mainframe.
  • Certifications or regulatory compliance.
  • Cost savings: reducing the bill is FinOps work, and it is measured afterwards.
  • Changes in production outside the agreed window or without prior written authorisation.

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

07 · Choosing

Cloud or DevOps as a Service: which one you need

  • Cloud: projects with a start and an end

    Designing, deploying or migrating the platform, and closing with a documented handover.

    Scope, deliverables, phases and budget in writing before we start.

    If the work has an end date and a closed deliverable, it is Cloud.

  • DevOps as a Service: ongoing operation

    Ongoing operation and improvement of the platform, in agreed hours and with a named technical team member.

    A block of hours or a monthly plan with defined hours, with plans from 20 hours.

    You can start with a Cloud project and, if needed, continue with DevOps as a Service to maintain it.

08 · FAQ

Cloud architecture FAQ

What is a landing zone and what is it for?

It is the orderly foundation of your cloud account: account or subscription structure, identity and permissions, network, activity logging and budgets. It lets you build on top without improvising, and adding environments or teams later does not force you to redo what came before.

What does cloud architecture design include?

An architecture document with a diagram and justified decisions, the landing zone, basic cost budgets and alerts, and the infrastructure code with a usage guide. It ends with a handover to your team; ongoing operation is a separate service. Everything is documented.

What is the difference between Cloud and DevOps as a Service?

Cloud is project work with a start and an end: designing, deploying or migrating the platform. DevOps as a Service is continuous operation and improvement during agreed hours. You can start with a Cloud project and, if needed, continue with DevOps as a Service to maintain it.

Do you work on AWS, Azure and Google Cloud?

Yes, on all three. We recommend the cloud that best fits your application, your team and your current contract, and we document the decisions. Everything lives in your company’s accounts, not in Nubyron accounts. Each project has a single cloud destination.

How long does it take to design a landing zone?

It depends on the number of accounts, the identity and network requirements and what already exists. We do not give generic timelines: after a first conversation we set the scope, deliverables, calendar and budget in writing before we start. There is no standard timeline.

How is it quoted?

Tailored to your case. After a first conversation to understand it, we send you a written proposal with scope, deliverables, phases and budget, before we start. We do not publish rates. If the scope changes, the change, its cost and its timeline are agreed in writing before they are applied.

Can there be downtime during a migration?

It depends on each system. We decide together in the plan, with its window, its risk and its rollback, and we do not promise that there will be no downtime. In some cases, replicating the data and shifting traffic gradually allows it to be shortened, but it is assessed case by case.

Do you always recommend Kubernetes?

No. Only when its complexity pays off. If it does not fit, we tell you and suggest alternatives, such as managed containers or a PaaS. We look at the number of services, the frequency of releases and whether your team can operate it before proposing it.

First step

Tell us what you need

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.