Server and IT infrastructure migration to our Riga data centre
Most migrations go wrong in the planning, not in the copying. We survey what you have, write down the order of moves and the way back, rehearse the switch, and only then touch production.
How we keep the risk down
Nothing moves before it is understood
We map what runs where, what depends on what, and which forgotten service everything quietly relies on. Surprises are found on paper, not at 3 am.
Every step has a way back
The old environment stays available until the new one has proven itself. If something is wrong, we go back instead of improvising.
The switch is rehearsed
Data is copied and the systems are started in the new environment for testing before the real cutover, so the cutover itself is short and boring.
We do not disappear afterwards
The first days after a move are when odd things appear. We watch the systems, fix what comes up and hand over a clear picture of the new setup.
What a migration project covers
- Survey of the current servers, systems and dependencies
- Choice of platform: dedicated servers, virtual, or colocation
- A migration plan with order, timing and rollback
- Moving servers and data, including physical relocation
- Network, VPN and firewall in the new environment
- Backup, testing, cutover and monitoring after launch
How a migration runs
- 1
Survey and plan
We inventory servers, systems, dependencies and working hours, then agree what moves in which order and what must not be interrupted.
- 2
Build and rehearse
The new environment is built and the data copied. Systems are started and tested there while the old ones keep running as normal.
- 3
Cut over and watch
The switch happens in the agreed window. Afterwards we monitor, fix loose ends and keep the old environment ready until you are satisfied.
Our own Tier 3+ data centre in Riga
Your services run on hardware we own and operate in Latvia, under EU jurisdiction. A second live region in the Netherlands, Dubai planned for 2026.
- N+1 redundant power and cooling
- Own BGP network with redundant uplinks
- Monitoring 24/7, engineers on site 9:00 to 17:00
- GDPR and EU data residency
Questions we get asked
How long will we be offline?
For most systems the interruption is measured in an evening or a weekend window, not in days, because the copying and testing happen while the old environment is still serving users. The honest answer depends on two things: how much data has to be synchronised at the last moment, and how many systems have to be switched together because they talk to each other. During the survey we say which systems can move quietly on a working day and which ones need a proper window, and that goes into the plan you approve before anything starts.
Can we move the physical servers we already own?
Yes. If the hardware is in reasonable shape, colocation is often the cheapest way to improve reliability quickly, and we arrange the transport, the rack, the power and the network. We will also tell you when we think a machine is too old to be worth moving, for example when it is out of warranty and its disks are near the end of their life. Sometimes the right answer is a mix: the newer servers move as they are, the ageing ones are replaced during the migration instead of a year later under pressure.
What if something goes wrong during the switch?
That is what the rollback is for. The old environment is not touched or shut down at the moment of the switch, it stays ready. If a system does not behave as it did in the rehearsal and we cannot fix it inside the agreed window, we go back to the old one and reschedule instead of leaving the company working on something half broken. It is a decision we take with you during the window, against criteria written down in advance.
What does the survey itself cost, and what do we get from it?
For a normal company setup the survey is part of preparing the offer and we do not invoice it separately. What you get is worth having even if you then decide to stay where you are: an inventory of what runs where, the dependencies nobody had written down, and a plan with an order of moves and a rollback for each one. Larger or unusual estates, several sites or a system nobody in the company still understands, take real engineering days, and in those cases we agree a fee up front rather than padding it into the monthly price later.
Can you work with our current IT provider?
Yes, and it usually goes better when we do. The person who has administered those servers for years knows things no survey will find in a day, and we would rather have them in the migration window than around it. We agree in advance who does what and who has the final say if something has to be decided at two in the morning. If the relationship is ending, we can also take the handover from them and become the single point afterwards.
Our contract with the old provider runs for a few more months. Is that a problem?
No, and it is often the comfortable case. The old environment stays where it is until the new one has proven itself, which is exactly the rollback we want anyway, so an overlapping contract buys you a safety margin instead of costing you. We plan the move so the paid period is used, not wasted. What does need checking early is the notice period and how the provider hands data back, because some want written notice months ahead and a few charge for the final export.
Ready to start?
Deploy in minutes or talk to an engineer about what fits your project.