Situation
A logistics company in Vilnius, Lithuania, with 80 employees runs two warehouses and its own vehicle fleet. All operations revolve around the warehouse management system: receiving, picking, dispatch, documents for drivers. When the system goes down, forklifts stop in the warehouse and lorries wait at the ramp.
The system ran on two physical servers in an office room, a server room that was really a former storage closet with an air conditioner. The servers were seven years old, their warranty had long expired, and one of them had shut down twice in the past year because of overheating. Each outage cost the warehouse several hours of manual work and delayed shipments.
On top of that there was a security problem. Drivers and warehouse staff connected to the system from phones and tablets through an open remote desktop port. The operations manager, seeing the questions customers were asking about suppliers’ cybersecurity, realised that this could not continue.
What was needed
With the operations manager and the finance manager we agreed on the goals:
- Remove the dependency on physical equipment in the office: stop buying servers and stop maintaining a server room.
- The warehouse system must run for both shifts, so the migration had to be done with no more than a few hours of interruption, over a weekend.
- Secure access from the warehouses, from the road and from home, with no open ports on the internet.
- Backups in more than one location and a written recovery time that can be shown to customers.
- Updates and maintenance no longer the company’s concern.
- A deadline of the start of the peak season, about five weeks away.
What we did
Week 1: audit and plan
We measured what the system really uses: processor load, memory and disk operations at peak hours. This mattered because the warehouse system vendor had recommended considerably more resources than were needed in practice. We agreed the database migration procedure and the test scenario with the vendor. We drew up a migration plan with a rollback option in case anything failed.
Week 2: the cloud environment
In our data centre in Lithuania we prepared three managed cloud servers: for the application tier of the warehouse system, for the database, and for the accounting system, which until then had shared a server with the warehouse system. Bitdefender GravityZone, monitoring and automated update management were installed on all servers.
In parallel we built a VPN network connecting the two warehouses, the office and the cloud. For mobile devices we provided a VPN client with two-factor authentication. The open remote desktop port was closed.
Week 3: trial migration
We moved a copy of the system to the cloud and for two days let the warehouse managers work in the test environment: receiving goods, picking, printing documents. This is where the hardest part surfaced. The label printers in the warehouses were configured against the old server’s IP address, and some of them had no documentation at all. Over two days we went through all 14 printers and fixed the configuration over the VPN.
Week 4: migration
We carried out the migration on a Saturday night. We stopped the old system, moved the final state of the database, and switched over workstations and devices. The warehouse manager checked the main scenarios on Sunday morning. The actual unavailability was about four hours, all of it outside working hours. The old servers stayed powered on for two more weeks as a fallback and were then shut down.
Week 5: backups and maintenance mode
We enabled server backup with Veeam: daily backups stay in Lithuania, and a second copy goes to an Amazon data centre in Germany. We tested and measured recovery: the entire warehouse system is restored from backup in under three hours, so we wrote a four-hour RTO into the contract with some margin. The update window was agreed for the night from Tuesday to Wednesday, when the warehouse is quietest.
Result
In the first six months after the migration, the warehouse system had not a single unplanned outage. We measure this with a monitoring system that records every minute of unavailability, and the customer receives a report every month. Planned updates run at night and employees do not notice them.
The agreed recovery time is 4 hours, confirmed by a real test, not by calculation. Backups are kept in two places: Lithuania and Germany. This let the operations manager answer customers’ security questionnaires with concrete facts instead of promises.
The office server room has been dismantled and the air conditioner switched off. The finance manager replaced the server refresh line in the budget with a monthly service fee that is known in advance.
“I used to check on Monday mornings whether the servers were alive. Now I only check the report.”
What we would advise in a similar situation
- Measure the real load before moving servers. Application vendors’ recommendations often carry a large margin, and you will pay for the resources every month.
- Do a trial migration and let real employees work in the test environment. Printers, scanners and integrations with suppliers only surface that way.
- Write the recovery time into the contract only after a real test. Four hours on paper and four hours in practice are not the same thing.
- Close open remote desktop ports immediately, before any migration. It is the most common way ransomware gets into logistics companies.
