According to Travel Weekly, Ryanair’s website will be down for 3 days while they make some pricing changes to their website (between Feb 16th and 18th) (Ryanair are an Ireland based low cost airline)
Read the Travel Weekly article
I have no inside knowledge of how Ryanair run their website but 3 days? Are they serious? That is rather a long time.
I can only think of a couple of reasons why a site would need to be down for 3 days……
- They are making a political point about how hard it has been to comply with the new website upfront pricing legislation….. but taking it to this extreme would be a bit much
- They are making a significant DNS change to their domain name…… but even then – this could have been handled is a faster way (I expect)
- They are making a significant reservation system change – and may be having to transfer old data from one system to another and then manually auditing the data transfer (when you have to transfer live data, often these changes have to be sequential and not done ahead of time)
- They have to reload pricing in a different way to how they currently load pricing – and this price load can’t be done in an offline system – only the live online system – but if they make the changes to live loaded prices prior to corresponding functionality changes on their website something breaks or causes user confusion.
Somehow there must be some manual process to cause a 3 day delay. My bet is on the 4th – which is probably why they have taken so long to get around to this project.
If I am right, the process will be something like this:
- Take system down
- Change loaded prices in live reservation system (manual process – could take a long time)
- Upload new website functionality that corresponds to new style of loaded prices
- Put system back up
Ummm……. At this stage I would start to look at a DataLoad – a mechanism to systematically upload data into any application – even legacy green screen applications….. if you could cut down the manual load process to a couple of hours this could get their site up after 24 hours (perhaps!). You can also do “trial runs” prior to the changeover event to ensure everything will go smoothly.
If someone from Ryanair thinks I have saved them a few million dollars in lost sales with this tip, please send contributions to me (and corresponding self-bill invoice). Thanks


Blog home




I don’t work directly with Ryanair but from my knowledge of airline CRSs I think it is the third option.
A change from openskies to newskies is significant, also there’ll be a sizeable data migration (I’d guess about 300,000 bookings – manual load is out of the question, there are almost certainly automated tools but I think they will simply take time to run or some percentage of bookings requires some manual intervention).
I’m not sure what you said about pricing holds true, in most airlines the prices lists are surprisingly static, and could in theory be loaded before cut over. Prices don’t appear static to consumers because any one flight could have dozens of price points. The dynamic nature of Ryanair pricing comes from the way yield/revenue management controls the inventory.
Or maybe I misunderstood your point…
Sorry, did I say 300,000? I should have said 2 million!
(Based on 50m PBs per anum, avg 2 PBs per PNR, and an avg booking lifetime of about 1 month = very rough guess)
Hi Mark
Thanks for commenting
When I said price reloading I thought that maybe their prices work like so
- base price
- flexible incremental price
- taxes & whatnot
Where the base price remains static but the flexible price, well, flexes.
I thought that maybe they were moving the relationship between what was in their static pricing vs what was in their flexible component. However now I understand it is a system change – therefore, yes, 3rd is more likely.
I know what you mean re yield for flights…. and price or class based yield – or a bucket approach…. I don’t know what Ryanair do though. Probably a form of bucket. (I have never had hands on use with Navitaire – but have worked at airlines that use it….)
Dataload tool I mentioned still takes a time to run….. In my experience using it we got about 5x times performance of a fully utilised human…. You are restricted from running at top speed because the systems behind the scenes are having to process the new data …. and have been optimsied to process around what is OK for a human to wait for…. not to handle x hundred thousand in a short period….. (which is why all this all takes time, of course). Dataload doesn’t need coffee breaks though.
Since Ryanair revamped their website….disaster!!
It takes ages to search for flights now ( I have a broadband connection)
Website loads ok ..but try searching and its like using a dialup connection!!
Well, at least no one got hurt.
They were indeed upgrading their reservation system from OpenSkies to NewSkies. This was about a year in the works and it didn’t come off without some hitches. I actually implement NewSkies reservation systems, and I know first hand how difficult it is to roll out a conversion the size of Ryan’s (millions of bookings is accurate). They have recently gotten an update or two from their vendor to address those a few of the stability problems.
We’ve been watching the site from across the pond here in the US and have noticed small intermittent outages everyday. One can only hope they can get this under control.