Define the switch before the file
The goal is a safe first operating day in STRYK. Import is only one part.Set a cutover date at the start: from when will reservations, changes, payments and room moves be recorded only in STRYK? Without it, parallel operation creates conflicting truths.
Name one project owner who collects decisions, records approvals and can postpone cutover if a mandatory test fails.
Separate required, optional and archive data
Not every old record needs to become active STRYK data. Required data protects future operations; useful history can be optional; closed historical records can remain in an export archive.
Limiting scope improves quality. Preserve the untouched original export securely as the reference for later questions.
| Data area | Recommendation | Verification question |
|---|---|---|
| Room categories and rooms | Required | Is every sellable room assigned to one active category? |
| Current and future bookings | Required | Do dates, state, guest, category, room, price and payment state match? |
| Open invoices and deposits | Required or explicit handover | Is it clear which system closes the balance? |
| Returning guests and companies | Based on quality | Are identity, consent, contact and company links reliable? |
| Closed history | Archive | Does daily work truly need this record active? |
Make the export verifiable
Never edit the only export. Keep an untouched original and a working copy. Every table needs headers, stable source IDs and unambiguous dates.
Inspect ten deliberately varied cases, not only totals. Include multi-room, children, company invoice, partial payment, cancellation, room move, unassigned room, repeat guest and a block.
Four preparation steps
- 01Preserve the original
Store the original unchanged with export time and controlled access.
Original opens and has not been edited. - 02Normalise a working copy
Remove decorative rows and ambiguous formats; never guess business values.
- 03Keep source identifiers
Keep booking, guest, invoice and room IDs from the old system.
- 04Mark control cases
Record the ten control cases and expected outcomes in a separate checklist.
Build the STRYK foundation first
Do not import bookings into a provisional property structure. Configure hotel and invoice details, timezone, currency and language, then categories and rooms.
Use personal accounts and suitable permissions. Migration management, finance review and housekeeping each need the right access.
Approve the STRYK foundation
- Hotel, address, tax and invoice details are approved.
- Every room has a unique number and one active category.
- Capacity and occupancy match the sellable offer.
- Personal users and roles are tested.
Import in STRYK: profile, map and validate
Open Settings and Data migration. Create an import job, identify the source and upload the working copy. Profiling reads sheets and columns without creating productive hotel records.
Map each source column to a STRYK field. Automatic mapping is only a suggestion. Validation checks every row; blockers must be fixed and warnings reviewed.
The safe STRYK import flow
- 01Create import job
Settings → Data migration → New migrationChoose source, label and a deliberately limited domain.
The job belongs to the hotel and an accountable person. - 02Upload and profile
Upload the working copy and compare detected sheets and row counts with your control.
- 03Map columns
Review every target field. Do not guess IDs, status, dates, room, amount or currency from similar headers.
- 04Run validation
Separate blockers from warnings. Use the error report, correct the working copy and rerun deliberately.
The dry run is the approval basis
After validation, run the dry run. It shows what would be created, linked, updated or skipped without changing production. Reconcile expected counts, not only error status.
Open the ten control cases and verify relationships, not just individual fields. Approval requires both totals and case-level checks.
| Check | Expected | Pass criterion |
|---|---|---|
| Rows by domain | Matches approved export scope | Every difference is explained by row. |
| Duplicates and links | Existing records are linked deliberately | No guest, room or document is duplicated unintentionally. |
| Amounts | Open, paid and total reconcile | Control total and five individual documents match. |
| Stays | Dates, state, guest and room match | All ten control cases pass. |
Test six hotel workflows before cutover
Formally valid data can still fail operations. Test realistic end-to-end scenarios where the next team receives the correct state.
Let future users run the tests. Every deviation needs an owner, due date and retest.
Six mandatory test cases
- 01New direct booking
Complete a mobile direct booking and verify reservation, guest, rate, extras, policies and confirmation.
- 02Arrival before room is ready
Prioritise housekeeping, assign the room, complete cleaning and return ready state to front desk.
- 03Room move during stay
Move the room and verify occupancy and housekeeping both reflect it.
- 04Departure with partial payment
Review charges and recipient, record balance and verify the same final PDF in preview and download.
- 05Cancellation and released capacity
Cancel and verify capacity is correctly released.
- 06Daily start by role
Each role signs in separately and identifies its next three tasks.
Cutover with control
At write stop, export the delta since dry run, import it and repeat control totals. Then review the next seven days of arrivals, in-house guests, next-day departures, open balances and out-of-order rooms.
Communicate one clear rule: from cutover onward, work only in STRYK; log issues instead of entering them twice. Assign an available owner and fixed review times.
Go-live approval on the eve
- Old-system write stop is confirmed and communicated.
- Delta import and totals have no unexplained difference.
- Arrivals, departures, in-house guests, balances and blocks are checked.
- Every employee has a tested personal account.
- Owner and support path are set for the first days.
Stabilise the first week and close the project
Run a 15-minute review on each of the first five days. Convert every issue into an owner, deadline and retest.
Close the switch only when bookings and balances reconcile, mandatory workflows have run in reality, and the team no longer returns to the old PMS for decisions. Then apply archive and deletion rules.
