Switching coworking software: a migration checklist

Moving coworking software is a coordination job. The member list is one part of it. Future bookings, company relationships, payment arrangements and the questions arriving at reception all need a place in the plan.

Start by agreeing what will move, who will check it and when the new system becomes the place staff use. Avoid choosing a launch date until you understand the data and the work involved.

The editable migration checklist gives each task an owner, a status and a place to record evidence. It is a planning aid for moving between systems, not a promise that every supplier can import every item.

Make a data inventory

List the records you need to retain and where each currently lives. A useful starting point is:

• Members, contact details and membership status.
• Companies, billing contacts and the people attached to each company.
• Plans, start and end dates, agreed prices and billing schedules.
• Rooms, desks, opening hours and booking rules.
• Future reservations, including recurring bookings and their exceptions.
• Invoices, payment references, outstanding balances and credits.
• Events, registrations and tickets, where relevant.
• Documents, communication preferences and integration settings.

For each group, mark whether it will be imported, recreated, kept in an archive or excluded. Ask the receiving supplier to confirm supported fields and formats. Do not assume that a member import includes invoices, booking history or documents.

Keep a secure, unchanged copy of each export. Use the supplier’s agreed transfer method, and restrict access to people working on the move. The worksheet needs record types and validation notes; it does not need members’ personal information or payment credentials.

Agree how the data maps

Pick representative records before exporting everything. Include a solo member, a company with several people, a membership ending soon and a booking with an unusual arrangement your space relies on.

Work through how the old fields map to the new system. Similar labels can carry different meanings: a contact may not be a member, an invoice date may not be a payment date, and a resource name may not identify a unique room across locations.

Decide how duplicates, archived members and missing information will be handled. Assign a person to answer mapping questions. Record decisions once so they do not change midway through the import.

Protect bookings and billing

Choose which system owns new reservations during the transition. If bookings can still enter the old system, agree how changes made after the export will reach the new one. A second import without a matching strategy can create duplicates.

Handle payment connections as a separate workstream. Ask both suppliers and the payment provider which customer references, authorizations or payment arrangements can be reused, and which require member action. Do not copy payment credentials into a spreadsheet.

Agree where outstanding invoices will be collected and where the next recurring invoices will be generated. Check that the same charge cannot be issued by both systems. Include the person responsible for your billing records in this decision.

A useful handover note answers three questions: Where do new bookings go? Where are existing balances handled? Which system creates the next invoice?

This checklist does not prescribe an accounting treatment or a retention period. Your team’s existing requirements should inform the migration plan.

Rehearse with a small import

Use a test space or another supplier-approved environment. Prevent trial imports from sending real invitations, charging members or changing physical access unless those actions are explicitly part of an agreed test.

Check both totals and individual examples. Matching the member count is helpful, but it will not reveal a person attached to the wrong company. Matching a booking count will not reveal that recurring bookings moved into the wrong time zone.

Have the responsible staff check:

1. Member and company counts, with exceptions explained.
2. Plan assignments, start dates and membership status.
3. Future bookings, time zones, resources and recurrence exceptions.
4. Invoice and balance totals grouped by currency and status, plus representative records.
5. Permissions and integrations using safe test accounts.

Write down the result and repeat failed checks after the underlying mapping is corrected. Keep the original export so that you can distinguish a source-data issue from an import issue.

Prepare staff and members

Give staff a short guide to the tasks they will perform on the first day: finding a member, changing a booking, checking an invoice and getting help. Let someone who did not configure the system try those tasks.

Prepare the member announcement before the switch. Explain the date, where to sign in or book, what happens to existing reservations, whether payment action is needed and who can help. State only what your migration rehearsal has confirmed.

If members will use a new app, test the invitation and sign-in journey on an ordinary phone. Check the web route too. The move should not depend on every member installing an app on the same day.

Make the switch and reconcile

Before launch, agree how to pause or return to the previous booking process if a critical check fails. Decide who can call that pause and how changes made during the transition will be recovered.

At the agreed time, capture the final changes, carry out the import and run the same checks used in the rehearsal. Confirm the correct links are on your website and in member communications. Check that the intended system is now responsible for each booking and billing action.

Monitor the first real booking and the first billing cycle with the staff who own them. Record exceptions and resolve them individually. Retire the previous system only after required records are accessible, outstanding work has an owner and the transition has been reconciled.

Questions for your new supplier

Ask for a written scope: supported imports, exclusions, your preparation tasks, who validates the data, expected member actions, support during the switch and charges for the work. A migration estimate should depend on that scope.

When evaluating Kommonz, bring your current setup to a demo and use this checklist to discuss the move. If you are still comparing options, start with the twelve-workflow software checklist.

Research behind the checklist

The 2025 OfficeRnD tech-stack report identifies integration, implementation cost and member adoption as concerns within its own customer sample. The methodology covers 230 clients; it does not establish a universal migration timetable.

Public operator stack discussions also describe information and responsibilities spread across tools. This checklist turns those concerns into suggested planning tasks. It is not based on claimed interviews or a measured Kommonz customer migration.