Cloud migration & cloud networking

Your route to the cloud, engineered end to end.

CoreRoute plans and runs migrations to AWS, Azure and Google Cloud, and builds the network underneath them: landing zones, hybrid connectivity, network security and cost control.

  • AWS, Azure, Google Cloud
  • Infrastructure as Code by default
  • Rollback plan for every cutover
On-premises network connected through a transit hub to AWS, Azure and Google Cloud with non-overlapping address ranges On-prem 10.0.0.0/16 Hub transit · DNS firewall AWS 10.10.0.0/16 Azure 10.20.0.0/16 Google Cloud 10.30.0.0/16

// one address plan, one routing domain, no surprises at cutover

Services

From the first inventory to the last cutover

We take responsibility for the whole path: what to move, how to move it, and the network it will run on afterwards.

Migration assessment

An honest picture of your estate before anything moves.

  • Application and dependency discovery
  • Migration strategy per workload (rehost, replatform, refactor, retire)
  • Target architecture and cost estimate
  • Wave plan with risks and owners

Migration execution

Workloads moved in waves, with tested cutovers and a way back.

  • Server replication and replatforming
  • Database migration with change data capture
  • Cutover runbooks and rollback plans
  • Post-migration validation and hypercare

Landing zones

A cloud foundation that stays organised as more teams arrive.

  • Account, subscription and project structure
  • Single sign-on and least-privilege access
  • Guardrails, central logging and audit trail
  • Everything delivered as code

Hybrid & multi-cloud networking

Private, predictable connectivity between your sites and clouds.

  • Site-to-site VPN, Direct Connect, ExpressRoute, Interconnect
  • Hub-and-spoke with Transit Gateway or Virtual WAN
  • BGP routing and IP address planning
  • Hybrid DNS resolution

Network security

Segmentation and controlled traffic paths, not one flat network.

  • Segmentation and private endpoints
  • Cloud firewalls, WAF and egress control
  • Zero-trust access for administrators
  • Flow logs and traffic visibility

Cloud cost optimisation

Bills you can explain, including the network part that usually surprises.

  • Rightsizing and commitment planning
  • Data transfer and NAT cost review
  • Tagging and cost allocation
  • Budgets and anomaly alerts
Approach

How a migration runs with us

Short, visible steps. You see the plan, the progress and the risks at every stage.

  1. Discover

    Inventory of servers, data, dependencies and network flows. Business constraints and downtime windows.

  2. Design

    Target architecture, address plan, connectivity and security model, cost estimate.

  3. Build the foundation

    Landing zone and network deployed as code, connected to your existing sites.

  4. Migrate in waves

    A pilot first, then grouped workloads. Each cutover has a runbook and a rollback plan.

  5. Optimise & hand over

    Rightsizing, cost review, documentation and knowledge transfer to your team.

Network first

Most migration problems are network problems

Overlapping IP ranges, broken name resolution and unexpected data transfer bills stall more projects than servers do. We design the network before the first workload moves.

  • An address plan that will not collideRanges for every site, cloud and future region, agreed up front.
  • Name resolution that works both waysOn-premises systems resolve cloud names, and cloud systems resolve on-premises names.
  • Traffic paths you can drawClear routing through inspection points, with no hidden internet hops.
  • Egress costs known in advanceData transfer, NAT and inter-region traffic estimated before go-live.
# network/ipam.tf (excerpt)
locals {
  sites = {
    office_kyiv  = "10.0.0.0/16"
    aws_prod     = "10.10.0.0/16"
    azure_prod   = "10.20.0.0/16"
    gcp_data     = "10.30.0.0/16"
    reserved     = "10.40.0.0/13"
  }
}

# every route, peering and firewall rule
# is derived from this single source
module "transit_hub" {
  source = "./modules/hub"
  cidrs  = local.sites
}
Stack

Tools we work with every day

We pick native services where they fit and open-source tooling where portability matters.

Clouds

  • AWS
  • Microsoft Azure
  • Google Cloud
  • VMware

Migration

  • AWS MGN
  • AWS DMS
  • Azure Migrate
  • Migrate to VMs
  • rsync & native replication

Networking

  • Transit Gateway
  • Virtual WAN
  • Direct Connect
  • ExpressRoute
  • Cloud Interconnect
  • IPsec & BGP
  • WireGuard
  • Route 53 / Azure DNS / Cloud DNS

Code & operations

  • Terraform
  • OpenTofu
  • Ansible
  • GitHub Actions
  • GitLab CI
  • CloudWatch
  • Azure Monitor
  • Grafana
Engagement

Three ways to start

Begin with a fixed-scope assessment or bring us in for the whole journey.

Fixed scope

Assessment

For teams that need a clear plan and budget before deciding.

  • Inventory and dependency map
  • Target architecture and address plan
  • Cost estimate and wave plan
  • Written report and walkthrough session
Ongoing

Cloud & network support

For environments that are already in the cloud and keep changing.

  • Network changes and new connections
  • Monthly cost and security review
  • Incident help for connectivity issues
  • Agreed response times
Your accountsEverything is built in cloud accounts you own.
Your repositoriesAll code is committed to your version control.
Your documentationDiagrams, runbooks and decisions stay with you.
No lock-inYour team can run it without us after hand-over.
FAQ

Questions we hear often

Can we migrate without downtime?

For most workloads the downtime can be reduced to a short planned cutover window. Data is replicated continuously in advance, and the final switch is rehearsed. If a system needs true zero downtime, we plan that explicitly during the assessment.

Which cloud should we choose?

It depends on your existing licences, skills, compliance needs and the services you plan to use. We compare the options for your case and are comfortable with AWS, Azure and Google Cloud, so the recommendation is not tied to one vendor.

Do we need to move everything at once?

No. Many migrations run in a hybrid setup for months: part of the systems stay on-premises and are connected to the cloud over private links until they are ready to move.

Who owns the result?

You do. Accounts, code, credentials and documentation belong to you from day one. We work with the access you grant and can be removed at any time.

Can you help with an existing cloud environment?

Yes. We review and fix networking in environments that have grown without a plan: overlapping ranges, unclear routing, public exposure and high data transfer costs.

Do you work with companies outside Ukraine?

Yes. We work remotely in English and Ukrainian and plan cutovers around your time zone.

Contact

Tell us where you are and where you want to be

Send a short description of your environment and goals. An engineer, not a sales manager, will reply.

Write an e-mail

Useful to include

  1. What runs today and where: data centre, hosting, another cloud.
  2. Target cloud, if you already have a preference.
  3. Approximate size: servers, databases, data volume.
  4. Deadlines or contract end dates.
  5. Compliance or data residency requirements.