Campground PMS Migration Week-One Checklist

The new PMS login works. Tomorrow’s 50-amp pull-through is still only true in the old grid. Both can be true. That is not go-live.

Week one of a campground PMS switch is not a new login. It is the week inventory, future stays, money, and guest-facing doors tell the same story. You must export a real reservation file, map 30-amp versus 50-amp sites by name, reconnect channels, and keep the old grid readable. An iCal of blocked dates is not a migration. A Friday cold-cut on a holiday weekend is how you double-book a pull-through.

TL;DR

• Ask for a CSV of guests and reservation history before you sign. PitchCamp puts export, contract length, and exit fees in the cost sheet for a reason. Setup on enterprise tools can be $500–$5,000+.

• Firefly’s own trial is a 14-day ladder (units and map, then payments and policies, then guest portal). Onboarding is where they import reservation and guest data. A login on day one is not a live park.

• iCal moves blocked dates on a delay. It does not move rates, pet fees, or who paid. Use it as a safety net, not the cutover file.

• Hotel migration writeups translate: stored cards do not hop with the CSV (Stripe only ships PANs processor-to-processor). HotelTechInsight wants 24–72 hours of old-system read-only. At a park that is the old grid next to the new one.

• Related: keep the PMS if the phone is the leak. 3-year cost is the invoice job. This post is week one of the switch.

What counts as week one of a campground PMS migration?

Week one is the first seven days the new system is allowed to own live inventory. Training videos are not week one. A sandbox full of test reservations is not week one. Go-live is when a stranger can book site 14 on the guest site, the office can take a deposit, and Hipcamp cannot sell the same pad.

Firefly’s getting-started guide spends days 1–3 on property settings, amenities, unit class, and the map. Days 4–6 are payments, policies, utilities, POS, and add-ons. Days 7–9 are emails, SMS, kiosk, guest portal. Activate is days 13–14. That is a trial of a new park, not a rip of 180 future stays. Treat it as proof that “we logged in” is the wrong finish line.

PitchCamp says most parks complete a transition in one to two days if they time it for the off-season. Read that as a vendor claim for a small import with help, not a law. WebRezPro puts a typical hotel PMS migration at four to six weeks from kickoff to go-live. A 40-site campground is simpler than a 40-room boutique with six OTAs. It is not simpler than a spreadsheet.

If the calendar already tells the truth and the leak is voicemail, stop. That job is keep the PMS, fix the phone. Week one of a switch is for parks that already decided the system of record has to move.

What data should you export before you cut over?

Export future reservations, guest profiles, site types, rates, and a deposit ledger before anyone decommissions the old login. A screenshot of the grid is not an export. Neither is “support said they will handle it.”

PitchCamp tells you to ask, in writing: full guest list in CSV, all reservation history, fee to export, minimum contract, early termination. Do that while you still have leverage. After cancel, you are asking a vendor you just left.

WebRezPro names the minimum move set as future reservations, guest profiles, rate and inventory setup, and chart of accounts. At a park, inventory setup is not “room type DBL.” It is site 18, pull-through, 50-amp, 40-foot, sewer, pets extra, loop B, not for tents.

Pull these files, dated, onto a disk you control:

Historical folios from 2019 can live as a CSV in a folder. HotelTechInsight is blunt: completed-stay line items rarely import cleanly. Archive them. Spend the hours on stays that still have to check in.

Firefly onboarding will help transfer reservation and guest data if you are switching. That is still your file. Keep a copy. The new vendor’s import is a convenience, not your backup.

Why isn’t an iCal feed a migration?

An iCal feed is a list of blocked dates. It is not rates, guest names, pet policy, or who already paid. Smoobu describes the format as poll-based: the other side asks later, sometimes hours, sometimes a day. It does not send minimum stay. It does not send the guest.

Use iCal as a temporary safety net between old and new, or on a niche listing with no API. Do not use it as the cutover. A blocked square on Hipcamp is not a reservation with a $200 deposit and a 38-foot fifth-wheel that needs the pull-through.

iCal also has a known failure: circular overwrite. An old feed republishes open dates and frees a night you already sold. If you run iCal during week one, make one system the writer. The other is read-only blocks.

The markdown config argument is the opposite of iCal. Sites, hookups, and policies should be text you can read and move. Availability is a calendar. Do not smash them into one .ics URL and call it done.

How do you map sites, hookups, and rates so the new grid tells the truth?

You map every live site by number, amps, length, and rules before you import a single stay. Then you import stays onto those IDs. If you import first, you will spend Friday renaming “RV-12” into the pad the guest actually reserved.

Park-native mapping is the whole job:

1. Same site numbers. Guests booked “site 22,” not “Deluxe Full Hookup 3.”
2. Split types when amenities differ. 30-amp back-in is not 50-amp pull-through. Pet cabins are not tent pads.
3. Length and slide-outs as fields, not folklore in a sticky note.
4. Weekend vs weekday rates as rate plans, not a staff memory.
5. Holiday 3-night mins named by date, same as the LOS weekend fence you already run.

Walk the loop with the new map open. Site 7’s pedestal is 30-amp even if the old software said 50. The new PMS will happily sell the lie.

Lunaria Booking keeps that map in property markdown the calendar and the guest site both read. Git history is the audit of what changed during cutover. If your new vendor only offers a 40-field form, still keep a spreadsheet or markdown you control. Week one is when people “fix” a type and silently move three future stays.

Test three bookings before go-live: a 50-amp pull-through weekend, a 30-amp midweek, a pet cabin with the fee. If any of those land on the wrong pad, you are not in week one. You are still in sandbox.

What happens to deposits and stored cards?

Deposits in the old ledger do not become card tokens in the new one. Plan a money path: which stays are already paid, which need a new authorization, which you collect at the gate.

Stripe will move card data to another PCI DSS Level 1 processor, with that processor’s AOC and a hosted PGP key. Link-saved credentials do not transfer. Payment history is not in the PAN file. You retrieve history from the old dashboard and you do not close that account on cutover day.

HotelTechInsight says the same thing in hotel language: tokens are tied to a gateway. Switch PMS, often switch processor, guests re-authorize or you take a new card at check-in. Translate: the fifth-wheel arriving Saturday with “card on file” in ResNexus may be a cash guest in the new app until you collect again.

Do this in week one:

1. Flag every future stay as paid-in-full, deposit-held, or balance-due.
2. Print or CSV the deposit amounts. Do not trust a single total.
3. Start the processor-to-processor transfer if both sides are PCI Level 1. It is measured in weeks, not an afternoon.
4. Write the gate script: “We switched software. We need a card for the remaining balance.” Put it on the confirmation too.
5. Keep the old merchant portal live through the last stay that was charged there. Refunds do not care about your new login.

Firefly tells trial parks to knock out payment processing early because it slows everything else. Believe that. A pretty map with no money path is a brochure.

How should old and new systems run in parallel?

Run the new PMS as the writer and the old PMS as read-only for at least 48 hours of real arrivals. Cold-cut Friday of a holiday weekend is how a confirmation email and an empty grid meet at the gate.

HotelTechInsight wants 24–72 hours of overlap, extra staff, and write access pulled from the old system so people stop typing into it. WebRezPro prefers a planned cutover over a long two-system life. Both can be true. The park version is: pick a dead Tuesday, not July 3. Keep the old grid on a tablet for 48 hours. Nobody creates new stays in it.

Failure mode is staff habit. Site 9 walks in. Someone opens the software they have used for eight years and sells it again. Fix that by password and by a paper sign on the old monitor: reference only.

Reconcile every morning of overlap:

1. Tonight’s arrivals: old list vs new list vs actual rigs.
2. New reservations since yesterday: only in the new system.
3. Channel holds: Hipcamp/Airbnb vs the grid.
4. Money: deposits taken in the new processor actually show on the stay.

If a stay exists in old and not in new, add it by hand before the guest is in the driveway. That is the entire point of overlap.

What guest-facing doors have to flip together?

The guest site, the office booking path, the phone, and every OTA or marketplace you left connected have to point at one inventory. Flip one door and leave the others on the old calendar and you invented a double-book machine.

WebRezPro says notify OTAs, POS, and lock vendors at least two weeks before cutover. For a campground that list is Hipcamp, Airbnb, Vrbo, The Dyrt, Spot2Nite, your WordPress widget, Google Business booking link, and the phone number on the highway sign. Two weeks is the email. Week one is the test.

Cannot wait, translated from HotelTechInsight:

• Channel reconnect and a test listing that cannot sell a real pad
• Payment processing that can take a deposit
• Site types and rates that match the loop
• One person who can check in, modify, and refund in the new UI
• Phone and walk-up that write the new calendar

Can wait: fancy SMS journeys, POS recipe counts, custom dashboards, the kiosk, the pretty map polish. Firefly puts those in days 7–12 of a trial. Fine. Do not block go-live on a kiosk.

The guest site has to complete a reservation without “we will call you back to confirm the new system.” The voice path has to read the same 50-amp truth. Lunaria Booking runs both off the same markdown. If your new PMS cannot, you still need one script and one grid. Two stories is how you refund a pull-through.

What mistakes blow the first weekend?

Five mistakes blow the first weekend: iCal-as-import, wrong site types, two live calendars, cards that did not move, and a holiday cutover with no extra hands.

1. iCal as the reservation file. You get blocks, not deposits. Guest name is “Blocked.”
2. Types mashed together. Every RV pad is “RV.” A 30-amp back-in sells to a 50-amp pull-through booking.
3. Old widget still live. Google still points at the old book-now. Hipcamp still polls the old feed.
4. Card on file is theater. Gate cannot take a balance. You eat the stay or fight in the driveway.
5. Cutover on a sold-out Friday. No time to reconcile. Every error is a guest.

A quieter sixth: deleting the old login on day one because you are “done.” Keep read-only for 30 days, archive for six months. Folio questions arrive after Labor Day.

If you have not done the fit test or the 3-year cost sheet, week one is the wrong week. Switching because a demo was pretty is how you buy a second onboarding.

What should you do this week?

Do not redesign the brand this week. Get one writer system, one export, and one reconcilable night.

1. If you have not signed, get the export answers in writing: guest CSV, reservation history, fee, contract, who imports. PitchCamp’s question list is a decent start.

1. If you already signed, export tonight. Date the files. Do not wait for the onboarding call to “send whatever you have.”

1. Build the site map in the new system before importing stays. Walk 10 pads. Confirm amps and length.

1. Start payment processing now. Firefly is right that this step eats days. Ask both processors about a PCI Level 1 PAN transfer.

1. Email every channel and the web person: cutover date, new widget URL, kill the old one. Two weeks if you can. This week if you already booked Friday.

1. Pick a dead midweek night as go-live. Extra person on the desk. Old grid read-only on a tablet.

1. Run three test bookings and one refund in the new processor. Then book one real stay on the guest site yourself.

1. Write the phone sentence: we switched software, your site is still 22, we may need a card for the balance. Same sentence on the confirmation.

If the new calendar cannot restrict a 50-amp pull-through to 50-amp rigs, stop decorating email templates. Fix inventory. A migration that only changes the login screen will still sell the wrong pedestal.

FAQ

How long does a campground PMS migration take?

Plan days of focused work, not an afternoon, and weeks of calendar if channels and payments have to reconnect. PitchCamp claims one to two days for many parks in the off-season. Firefly’s trial is a 14-day setup ladder. WebRezPro cites four to six weeks for hotels. A 40-site park with one marketplace should beat the hotel number. It should not pretend the login is the finish.

Should I switch in July?

No if you can wait. Off-season is the honest window. If you must switch in season, cut over on a quiet Tuesday with extra staff, not the Friday before a holiday.

Do I need to move ten years of history?

No. Move future stays, active guests, and a deposit ledger. Archive old folios as CSV or PDF. Front desk needs a folder, not a perfect 2018 folio in the new UI.

Can iCal keep Hipcamp in sync during the switch?

As a short safety net, yes, if one system writes and the other only blocks. As the migration, no. Smoobu is clear: iCal does not carry rates or guest details and it lags.

Will guest credit cards come over?

Not in your CSV. Stripe can send PANs to another PCI Level 1 processor. Plan re-authorization or gate collection for anyone whose token will not move.

What if the phone is the real problem?

Keep the PMS. Fix the phone. That is a different post: Keep Your Campground PMS, Fix the Phone. Do not buy a migration to solve voicemail.

Does Lunaria Booking import my old PMS?

You bring property truth as markdown: sites, hookups, rates, policies. The engine turns that into calendar, guest site, and a voice path that can book. You still export future stays from the old system and reconcile week one like any other switch. The difference is you are not re-clicking eighty vendor forms to describe a 50-amp pull-through.

---

A new login is a Tuesday. A migration is the week the loop, the money, and the guest doors agree. Export the real file. Map the pedestals. Keep the old grid readable. Then let one system sell site 22.