Solution · By task

Data localisation

Data on Kazakhstani citizens must be stored inside the country, and in recent years foreign services have also become an unreliable footing: payment, access and support can drop away without warning. A migration rarely breaks on the database itself - it breaks on forgotten dependencies, which is why we start with an inventory rather than with choosing a site.

A data centre in Kazakhstan
a site inside the country
Test
a trial migration before the live one
2 weeks
inventory and plan
Weekend
switchover outside working hours

What the solution includes

The move breaks into five parts. The first two matter most: without them the switchover is blind.

Send a request

Inventory

We compile a list of systems and services: where they physically sit, what data they hold and who actually uses them. Often this is the first such document the company has ever had.

Choosing the site

We choose hosting in Kazakhstan to match the data and load requirements: your own server, rented capacity or a local provider's cloud.

Dependency check

We look at what will break during the move: the accounting sync, mail, payments on the site, banking clients, integrations with outside services.

Migration

We move the data and settings to a schedule, with a trial run and a rollback plan. The switchover is scheduled for a weekend or overnight.

Support after the move

Enhanced support in the first weeks, when the rare scenarios surface, and setting up backups in the new location.

How the move goes

You cannot move everything in a single day. The scheme that works is a trial run, a review of the problems, then the live switchover with the option to roll back.

01

Inventory

Two weeks for the inventory of systems, data and dependencies. The outcome makes clear what must move and what can stay as it is.

02

Trial migration

We bring up a copy on the new site and test it against real data. It is cheaper to find a problem on the copy than on the live system.

03

Switchover

The live migration to a schedule, system by system, keeping the ability to return to the old site the same day.

04

Stabilisation

Enhanced support for the first month, tuning based on feedback, switching off the old services and taking them off the bill.

The most common surprise is not the database but the small things around it. A newsletter still going out from the old address, payments on the site tied to the previous domain, a report exported on a schedule from someone else's server. That is exactly why the inventory comes before the switchover, not after.

Questions and answers

If you process the personal data of Kazakhstani citizens, it must be stored within the country. For other systems there is no obligation, but there is a practical risk: access to a foreign service or the ability to pay for a subscription can stop without warning, and then the move becomes urgent and more expensive.

For a company with email, a website and an accounting system, four to eight weeks including a trial run. Most of the time goes not on copying data but on checking dependencies and agreeing the switchover window. If there are many systems linked by data exchange, they set the timescale.

A full stop is not needed. We bring up a copy in advance and keep it in sync, and schedule the live switchover for a weekend or overnight. Downtime is usually measured in hours, and we state how long before the work starts, not after.

There are options: run it on your own server inside the country, split the data so personal information stays here, or replace it with in-house software if the function is critical. Moving «every last service» is rarely necessary; usually it is enough to cover what falls under the requirements.

We will size up the move

Расскажите, какие системы используете и где они сейчас размещены. Проведём инвентаризацию и покажем, что переносить обязательно, а что можно оставить.