Season opening and closing: an IT checklist for seasonal hotels

A seasonal hotel IT checklist is a two-ended list: in autumn it closes accounts, copies data, updates and stores devices and confirms backups; over winter a named person checks them; in spring it renews licences, resets dates and clocks, creates new staff accounts and runs a full test day before the first arrival.

The hotel closes in October with everything working and reopens in April with a key encoder that thinks it is 2019, two licences that lapsed in January and the logins of staff who left a season ago. Nothing broke in the building. The systems simply went unwatched for five months. After reading this article you will have a seasonal hotel IT checklist covering all three phases: closing, winter watch and reopening, with an owner and a date against every line.

What is a seasonal hotel IT checklist?#

It is a written list with three parts: what you close and copy in autumn, who watches the systems over winter, and what you update, test and create in spring before the first arrival.

Keep the scope to systems. Closing the building, the pool, the kitchen and the housekeeping stock belongs to an operations checklist; two separate lists stop one from hiding the other. Our companion piece on closing a seasonal hotel for winter: an operations checklist covers that side.

Every line carries a name and a date. A checklist without an owner against each item is a wish list that gets signed in April without being done. Keep last year's signed sheet too: it shows what changed, who did it, and which line was skipped two years running.

Seasonal hotels fail differently from year-round ones. A year-round hotel finds a fault within days; a seasonal one finds it on opening day, with guests in the lobby and no time to order a part. The failure families are always the same: accounts nobody disabled, licences and subscriptions that expired quietly, devices with wrong dates or missed updates, and backups nobody ever restored.

Agree who does the work before the season starts: an in-house person, an outside IT company or the software vendors, with the boundary written down so each does not assume the other is watching. The question of who runs IT at a hotel deserves its own decision, not a default.

What should you close, copy and switch off when the season ends?#

Close accounts first, copy what you are required or likely to need, then update and power down the devices in a fixed order, writing down what you unplugged.

Accounts first: disable every seasonal staff account on the closing day, including the shared reception login, the restaurant till login and the housekeeping login. Disable rather than delete, so the record of who did what survives the winter. An account nobody watches is the easiest way into a hotel system.

Copy before shutdown: the season's guest ledger and folio history, the day-end reports, the reservation and cancellation history, and any record you must keep for a legal retention period. How long each must be kept depends on your case, so confirm it with your accountant and legal adviser. Compliance steps such as guest identity notification and electronic invoices have their own closing rules; our pre-season compliance checklist for seasonal hotels in Türkiye covers them separately.

Take a full backup at close, keep one copy off the property, and label it with the date, the contents and the person who made it. Update devices before storage, not after: a machine that sits unpatched for five months is five months of known holes waiting for opening week.

Power down in a fixed order: tills and payment terminals, key encoder, the machine that runs the hotel system, network switches and router, then cameras and the recorder. Photograph the rack and label every cable before you unplug it. Decide whether the network and cameras stay on: a recorder that fills its disk in an empty building in December is not security, so agree who checks it and how often.

Who checks the systems while the hotel is closed?#

A named person, following a written monthly routine, because the failures that hurt in spring are the quiet ones: a backup that stopped running, a subscription that lapsed, a recorder that filled its disk in December.

The monthly backup check is the most important line. Open the backup, confirm its date and size, and restore one file or one copy of the database onto a spare machine. A restore nobody has performed is not a backup; our guide to backups for hotel systems explains how to run this test safely.

Alerts need a route. A monitoring email that lands in the inbox of someone who left in October is not monitoring, so confirm the recipient list each month and that a person actually reads it. Do one physical walk-through a month: power, temperature, humidity, water leaks, doors and windows, and whether the recorder is still recording.

Keep a renewal calendar for the domain, security certificates, software subscriptions, licence keys, support contracts and card stock, with a reminder a month before each date. Keep a winter contact sheet: who to call for the network, the tills, the locks and the hotel system, and at which hours. Log each visit in one line; when something fails in April, the log tells you whether it failed in December or on the first warm day in March.

What has to be updated before the first arrival?#

Licences, updates, and above all dates and clocks: a device that sat unplugged for months comes back with the wrong date, and a wrong date breaks key cards, day-end totals and fiscal records.

Confirm every licence and subscription is active and held in the hotel's own name, weeks before opening, so a renewal problem is not discovered at check-in. Install updates in stages, one group of devices at a time, well before opening, so a bad update does not take out the whole property on day one.

Set dates, times and time zones on the hotel system, the tills, the key encoder, the cameras and the recorder, then check that the hotel system and the tills agree. If they do not, the day-end totals will not match and nobody will know which one is right. Check the domain and security certificates too: an expired certificate shows guests a warning page instead of the booking page or the guest app.

Order consumables and spares before the suppliers get busy: key cards, printer rolls, card stock, network cables and one spare terminal. Run one payment and one fiscal document end to end, and keep the practice of a person reviewing an electronic invoice before it is sent.

How do you set up staff accounts for a new season?#

Start from last season's user list rather than a blank page: re-enable the people who returned, create accounts for new staff, and leave everyone else disabled.

Use named accounts only: one login per person, no shared reception login. A shared login makes the record of who did what worthless exactly when you need it. Decide roles before names: what a receptionist, a night auditor, a housekeeping supervisor and a restaurant cashier may each do, then place people in those roles. Our PMS user roles and permissions setup checklist walks through this in detail.

Apply least privilege at the start: give the smallest set that lets the person do the job, and widen it when they ask and you agree. Re-enable rather than recreate, so a returning employee keeps their history and the reports stay readable. Handle mid-season departures too: disable the account the same day someone leaves and note who took over their open items.

Test each role with a real task before opening. A receptionist who cannot post a charge finds out at 23:00 on the first night, with a guest waiting.

What does a test day look like before opening?#

One full day of simulated business, end to end, performed by the people who will actually work the systems, with a written list of what passed and what did not.

Create a test reservation, assign a room, check in a test guest, encode a key card and open the door with it. Post a charge to the room, take a payment, and run the day-end process to close the test business day. Send a test electronic invoice and confirm that a person reviews it before it leaves the building.

Check the channel connection with a test rate and availability, then remove the test rate before opening, and confirm what the hotel's own website shows. Open the guest app or guest messaging on a phone that is not yours, and check that the bill and an offer appear as a guest would see them.

Write down every failure with the time and who fixed it. That list is the first page of next year's checklist.

Which support terms do you need before the season starts?#

Written support hours, a response time, an escalation name and a named person on the hotel side, agreed before opening rather than discovered during the first outage.

Support hours in season and out of season are often different. A seasonal hotel needs the in-season hours written into the contract, not assumed. Response time and resolution time are different promises: a fast answer that fixes nothing is not the same as a fix. Ask who is on call at night and at weekends and how the hotel reaches them; for a 23:00 failure you want a phone number, not a web form.

Agree what the vendor may change without the hotel's approval, and how a change is undone if it goes wrong. Keep a printed contact sheet at reception and a copy in the manager's file, because the network will be down at the moment you need to look it up. The vocabulary of these contracts, from response time to recovery objectives, is covered in our piece on support and uptime terms in hotel software contracts.

What to do next#

Open last season's sheet, add the three parts, close and copy, watch, update and test, and put a name and a date against every line. The parts fit together as one cycle: what you close carefully in autumn is what you can check over winter, and what you check over winter is what lets you open in spring with a test day instead of a rescue.