A real-world travel technology case study | 2015–2020
When a ransomware attack brought production systems down and threatened business-critical data, recovery depended on more than restoring servers. It depended on what we had managed to preserve.
Imagine arriving at work on Monday morning to discover that production systems are unavailable, important business records are encrypted, office computers are inaccessible, and a ransom demand is waiting.
For a travel business, this is more than an IT problem. Reservations, customer communication, financial records, operational workflows, and the technology supporting daily business can all be affected.
This was not a hypothetical scenario for me.
Between 2015 and 2020, while leading an in-house technology development team for a UK-focused travel business with operations and customers across international markets, I experienced multiple ransomware incidents firsthand.
The first incident was particularly severe. Attackers gained access to the production server and successfully encrypted it. IVR voice recordings, accounting data, executive computers, and other important business information were affected.
The attackers had managed to disrupt the technology supporting a functioning travel business.
But there was one thing they had not completely destroyed: access to critical development assets that would become instrumental in the recovery.
This is the story of what happened, how we recovered, and the lessons I learned about protecting the technology behind a travel business.
At the time, much of the business infrastructure relied on locally hosted servers.
The first ransomware incident compromised the production environment, leaving important systems and data encrypted. The impact extended beyond the development team to business operations and senior management.
The attackers demanded payment in exchange for restoring access to the encrypted information.
For the business, the immediate questions were straightforward but serious:
There was no room for a theoretical discussion about disaster recovery. We needed a practical way forward.
I had a dedicated development computer connected to our Team Foundation Server (TFS) source control environment.
My development setup contained several important assets:
There was also an unusual amount of video content on my machine. I regularly downloaded programming tutorials and technical training videos to watch during my free time. Some drives contained hundreds of gigabytes of these files, alongside important development material.
During the first incident, my computer was partially affected by encryption, but the attackers did not completely destroy the critical development assets we needed.
I cannot say with certainty why my machine escaped more extensive encryption. The video files and additional drives were simply part of the environment I happened to have at the time, not a deliberate ransomware defense strategy.
What mattered was that we retained access to important assets needed for recovery.
The experience reinforced a lesson I have never forgotten: when production systems fail, the ability to recover depends heavily on what remains accessible and usable outside the affected environment.
The ransom demand did not determine our next move.
With important development assets still available, we could work towards restoring the business rather than depending on the attackers to provide a decryption key.
The recovery involved regaining control of the technology environment, restoring critical application capabilities, and bringing essential systems back into operation.
We subsequently moved the infrastructure from the local hosting environment to AWS as part of our technology evolution.
That transition was an important milestone in the journey. It gave us an opportunity to reconsider how the business hosted and operated its technology.
The first incident had demonstrated how disruptive a successful ransomware attack could be. It had also shown the importance of having recoverable source code, database copies, and the technical knowledge required to rebuild critical systems.
It would have been reassuring to think that the first incident was an isolated event.
Unfortunately, that was not my experience.
Over the following years, attackers made further attempts. According to my recollection, there were five incidents or attempts during the 2015–2020 period.
On subsequent occasions, computers across the office were affected, and significant disruption occurred. My own development environment was not completely immune; some publicly shared folders were affected during later incidents. However, the attackers did not completely compromise the critical development assets in the way I had feared.
Each incident reinforced the need to distinguish between losing access to an individual computer and losing the ability to rebuild the business's technology.
A computer can be replaced. A server can be provisioned again. But recovering a complex travel application, its business rules, database structures, supplier integrations, and operational workflows can be much more difficult if the underlying assets are lost.
For a travel technology business, that distinction is critical.
Travel businesses depend on interconnected systems.
A typical online travel agency or travel management business may rely on:
When the underlying technology is unavailable, the impact can extend far beyond a website being offline.
Employees may be unable to access essential information. Booking operations may be disrupted. Customer service teams may lose access to communication records. Technical teams may have to reconstruct application environments while the business waits for services to resume.
This is why technology resilience should be considered a business continuity requirement, not simply a server administration task.
Looking back, I would not describe our experience as a perfect security strategy. We faced real incidents, suffered disruption, and were fortunate to retain access to important development assets.
However, the experience left me with several lasting lessons.
Source code is not merely something developers use to build new features. For a business with years of accumulated functionality, it represents a significant investment in intellectual property and operational knowledge.
Maintaining protected, recoverable copies of source code can make a substantial difference when production systems are compromised.
Having a backup file is not the same as having a working recovery plan. Backups need to be protected from the same incidents that can affect production systems, and restoration should be tested.
A business should know which data it needs to recover first and how long essential services can reasonably remain unavailable.
A development environment may contain source code, database copies, configuration files, and other information required to rebuild an application.
These assets should not automatically be treated as safe simply because they are separate from production. Access controls, network isolation, protected backups, and tested recovery procedures all matter.
Restoring a server is only one part of recovery.
Travel technology often includes supplier connections, application configuration, booking workflows, payment integrations, and business-specific rules. Recovering these capabilities requires both technical knowledge and an understanding of how the business operates.
Moving workloads to cloud infrastructure can change how systems are deployed, managed, and recovered. However, cloud hosting alone does not prevent ransomware or guarantee that data can be restored.
The security and recovery model must be designed alongside the infrastructure.
Despite the disruption and repeated incidents I witnessed, the travel business continued operating and serving its markets.
I remained focused on the practical challenge of keeping its technology running, preserving the assets required for recovery, and supporting the business as its infrastructure evolved.
I do not attribute the business's continued success to one computer, one backup, or one technical decision. Businesses survive difficult periods through a combination of people, operational decisions, recovery capabilities, and sustained effort.
Nevertheless, retaining critical development assets made a meaningful difference to my ability to help recover the technology after the first incident.
That is the part of this experience I remember most clearly.
Today, when I think about those incidents, the most important lesson is not about the ransom demand or the number of computers affected.
It is about the difference between a business that has lost access to its systems and a business that has lost the ability to rebuild them.
The first situation can be extremely disruptive. The second can be far more difficult to overcome.
For travel businesses investing in digital platforms, reservation systems, integrations, and customer-facing technology, resilience deserves attention from the beginning. Source code, databases, infrastructure, credentials, and recovery procedures all form part of the business's technology foundation.
At Sopra Travel Technology, our work focuses on building and integrating travel technology that supports real business operations. Experiences like these have shaped my understanding of the operational realities behind the software we develop.
Because building travel technology is important. Being able to recover it when things go wrong is equally important.
Whether you are building an online travel agency, modernizing an existing reservation platform, or integrating multiple travel suppliers, your technology decisions should account for operational continuity as well as functionality.
Explore Sopra Travel Technology's travel technology development and integration services to learn more about our work with travel businesses.
This case study is based on the author's personal experience and recollection of historical incidents encountered while working with a travel business between 2015 and 2020.
To respect confidentiality, protect the interests of the business involved, and avoid exposing sensitive information, we have intentionally withheld identifying details, original correspondence, technical evidence, and other potentially sensitive records from public disclosure.
The account is shared for educational and professional awareness purposes, highlighting practical lessons in technology resilience, business continuity, and recovery planning. It is not intended to identify, accuse, or make allegations against any specific individual, organisation, or geographic region. Certain details have been generalized to preserve confidentiality.
Editorial note: This case study is based on the author's recollection of incidents experienced while working with a former travel business. The business has not been named. Incident details and technical observations are presented as personal experience rather than an independent forensic investigation.
Fill in the details below and our travel technology expert will get back to you with the right advice.
