Coworking software migration: a practical playbook

Switching coworking management software is not really a software problem. The interface differences between platforms are usually small. The hard part is moving live data — members, active subscriptions, unpaid invoices, payment mandates — without breaking anyone's billing, and doing it in a window your team can actually manage. This guide is a practical playbook for that move: what to export, what genuinely cannot be transferred, how to map the data, and a realistic week-by-week timeline. It applies whether you are leaving OfficeRnD, Nexudus, Cobot, a spreadsheet, or anything else, and whichever platform you are moving to.

When to switch

Cut over at a billing-cycle boundary, never mid-cycle. If your members are billed monthly on the 1st, your cutover date is the 1st — not the 14th. Switching mid-cycle means splitting a billing period across two systems, which produces partial invoices, confused members, and reconciliation you will be doing by hand for weeks.

Avoid your busiest month. If you run a coworking space, you know which month that is — the one with the highest churn risk, the one where a new-member surge overlaps with renewals, or the one your team is already stretched covering events. Migrating software on top of that is how a manageable project turns into a support-ticket pile-up.

Plan for one full billing cycle of parallel running before you fully cut over — old system still live, new system standing up in the background, both producing invoices you can compare. That single cycle is what actually proves the new system is ready, not a demo or a data-import summary.

What to export from the old system

Before you touch the new platform, get a complete export from the old one. At minimum:

• Members and companies — names, contact details, company affiliations, tags or segments you rely on for reporting or communication.
• Membership plans and their prices — every plan currently in use, including ones no longer sold but still held by existing members (legacy pricing matters — see below).
• Active subscriptions with renewal dates — who is on what plan, when it renews, and any custom pricing or discounts applied to individual members.
• Open and unpaid invoices — anything outstanding needs to follow the member, not get lost in an archive you stop checking.
• Historic invoices, for tax retention — both India and the UK require multi-year retention of invoicing records. Confirm the current retention period with your accountant; do not guess it, and do not assume the old vendor will keep your data accessible indefinitely after you leave.
• Bookings — at minimum, any recurring or future-dated bookings that need to exist on day one in the new system. Historic booking data is usually lower priority than the financial records above.
• Credit balances — any member credit, whether from an overpayment, a refund issued as credit, or a goodwill gesture, needs to carry over as a tracked balance, not disappear.
• Payment mandates — the list of who has an active card, Direct Debit mandate, or UPI mandate on file, even though (as below) the mandate itself usually cannot move with the data.

Get this export in a plain format — CSV is the common denominator — and check it while you still have access to the old system, so you can re-pull anything incomplete.

The mandate problem

This is the genuinely hard part, and worth being blunt about: card tokens and Direct Debit or UPI mandates generally cannot be transferred between providers. A card saved against a Stripe customer in your old system does not travel to a new Stripe (or Razorpay, or GoCardless) account in your new one. A GoCardless Direct Debit mandate or a Razorpay UPI Autopay mandate is tied to the payment processor relationship it was created under, not to your coworking software. Every member on recurring billing will need to re-authorise payment in the new system.

This is the single biggest cause of failed migrations and churn during a software switch. It is not a data-import bug to fix — it is a structural fact of how card networks, Direct Debit schemes and UPI mandates work, and any vendor claiming otherwise is describing a narrower case than yours.

Plan communications around it deliberately rather than treating it as a footnote in a "we've upgraded our systems" email. A realistic member-comms sequence:

1. 3–4 weeks before cutover — tell members you are switching software, explain that they will need to set up payment again, and give a firm date by which it needs to be done.
2. 1–2 weeks before cutover — send the actual link or instructions to re-authorise payment, and flag that their next charge depends on it.
3. At cutover — send a short, direct reminder to anyone who has not yet re-authorised, ideally with an in-person or front-desk nudge for members who are on-site regularly.
4. First billing run in the new system — chase failures immediately rather than letting a failed collection sit. The first cycle after a migration always has the highest failure rate; budget staff time for it.

Members who ignore this are not being difficult — recurring payment setup is exactly the kind of admin task people put off. Build follow-up into the plan rather than hoping the first email lands.

Data mapping gotchas

A handful of details break silently if nobody checks them:

• Minor units vs decimals. Some systems store money as decimals (129.00), others as integer minor units — paise or pence (12900). Getting this wrong during import either divides or multiplies every price by 100. Check a sample of imported prices against the source before you trust the bulk import.
• Tax-inclusive vs tax-exclusive prices. A plan priced at ₹10,000 inclusive of GST is a different number from ₹10,000 plus GST. Confirm which convention the old system used for every plan, not just the ones you remember, and confirm the new system's convention matches or is mapped correctly.
• Timezone on bookings. A recurring meeting-room booking at "9am" needs to land on the same wall-clock time in the new system, not shift by whatever timezone difference exists between how the two platforms store timestamps. This is easy to get wrong for spaces near a timezone boundary or for any multi-location operator spanning zones.
• Proration mid-cycle. If a member upgraded or downgraded partway through their current cycle in the old system, that partial-period adjustment needs to be reflected correctly, not reset to a full-price renewal on the new platform.
• Deposits and credits. Security deposits and member credit balances need to carry over as tracked, reconcilable amounts — not get folded into a lump-sum "starting balance" that loses the underlying detail your accountant will eventually ask about.

A parallel-run checklist

The way to catch all of the above before it affects a member is to run both systems for one real billing cycle and reconcile them line by line:

• Issue one invoice per market (India, UK, or wherever you bill) in both systems for the same member and plan.
• Compare the totals. They should match, or the difference should be explainable (a mid-cycle proration difference, for example — not an unexplained rounding gap).
• Compare the tax lines specifically. GST and VAT are where minor-units and inclusive/exclusive mistakes show up first, because a small base-price error compounds into a visibly wrong tax amount.
• Only once a full cycle reconciles cleanly — invoices, totals and tax lines all matching — switch live collection over to the new system.

This is slower than a straight cutover, but it is the only version of "migrate the billing system" that does not risk charging members the wrong amount.

A realistic timeline

A typical migration for a single-location or small multi-location operator runs four to six weeks:

• Week 1 — export everything from the old system; confirm your tax-retention requirements with your accountant; pick your cutover date against a billing-cycle boundary.
• Week 2 — import members, plans and active subscriptions into the new system; spot-check a sample against the source data for the mapping gotchas above.
• Week 3 — begin the member-comms sequence for payment re-authorisation; run your first parallel invoice batch and reconcile totals and tax lines.
• Week 4 — chase outstanding re-authorisations; run a second parallel cycle if the first surfaced any discrepancies; finalise which bookings and credit balances move across.
• Week 5–6 (if needed) — cut over live collection to the new system at the billing-cycle boundary; monitor the first live billing run closely and follow up on failures fast.

Larger or more complex estates — several locations, unusual membership rules, high transaction volume — should budget toward the longer end, or longer still. The constraint is rarely the import; it is the pace at which members actually re-authorise payment.

How ofyse fits

If you are evaluating ofyse as the destination, a few things make the process above more manageable, and a few things do not change.

The 30-day free trial, with no card required, is long enough to run a genuine parallel billing cycle before you commit to anything — set up your locations, import members and plans, and issue real invoices in the trial period rather than testing with dummy data. CSV import covers members and plans, so the bulk data move in the checklist above is not a manual re-entry job. And because ofyse produces GST-correct invoices for India and per-line VAT invoices for the UK, the parallel-run reconciliation step has something concrete to check the old system's invoices against, rather than eyeballing totals. If you want the detail on either market's tax handling, see the guides on GST billing for coworking in India and VAT for coworking spaces in the UK.

What ofyse does not change is the mandate problem. If you move to ofyse and use Razorpay UPI Autopay or GoCardless Direct Debit for recurring collection, your members still need to set up a new mandate — that structural fact holds regardless of destination platform. The UPI Autopay and GoCardless Direct Debit guides cover how each works day to day, worth reading before you write the member-comms sequence above. Historic invoice archives are the other piece that stays manual: export and keep your old invoices for as long as your accountant advises, since a new platform will not retroactively hold records from before you joined it.

None of this is specific to ofyse — it is the honest shape of any coworking software migration, and it is worth taking the same list of questions into any vendor conversation, including this one. If you are still comparing platforms, the best coworking space management software roundup and the pricing page are reasonable next stops.