Skip to main content
Sign in
Français

How to switch a building between Managing Agents

  • Updated

Use this guide when a building currently managed on Dwellant needs to move from one Managing Agent (MA) to another.

Important warnings

  • Authorisation must come from the incumbent / outgoing MA.
  • The switch cannot be undone once completed.
  • Records will be removed from the original MA’s live Dwellant site.
  • Accounting package data is not changed by the switch itself.
  • Dwellant may decline a switch if it cannot be completed while preserving data quality.

When to request a switch

A switch may be appropriate where the building has meaningful Dwellant data or services to preserve, including:

  • Concierge HV
  • Bespoke portal
  • Compliance records
  • Well-established posting or communication history
  • Resident/user history
  • Documents, contracts, requests or forms
  • Existing Dwellant Core setup used by the new MA

When a switch may not be needed

A switch may not be appropriate where:

  • The new MA does not use Dwellant
  • There is limited data to share
  • The building can be recreated more cleanly
  • The history is complex, disputed or likely to be questioned
  • The transfer would create duplicate or unreliable data

Switch scenarios

ScenarioLikely routeNotes
Complete loss, new MA not on DwellantOffboard / archiveUsually not a true switch. Export required data and disable/archive as agreed.
Complete loss, new MA on DwellantLift & Drop, or Clone & Merge

Depends on whether the new MA has already synced accounting or created duplicate data.

Lift & Drop = Unsync existing building from old MA and move directly to new MA

Clone & Merge = Create a second building, merge important data and delete off the rest

Partial loss, new MA on DwellantCustom planRequires review of blocks, shared users, HV, accounting and data structure.
Movement within an operating groupInternal seeding / clone processFollow the internal operating-group process.

 

Before submitting a request

Please confirm:

  • Building name and address
  • Outgoing MA and authorised signatory
  • New MA and authorised signatory
  • Target switch date
  • Whether the new MA already uses Dwellant
  • Whether the new MA has already synced accounting for the building or units
  • Whether resident communications should be paused during the switch

What not to do

Please do not:

  • Ask Dwellant to proceed without outgoing MA authorisation
  • Sync accounting before Dwellant confirms it is safe
  • Create duplicate buildings or units manually unless instructed
  • Announce to residents before verification and sign-off
  • Leave offboarding exports until after old access is removed
  • Assume every historic item can be transferred in every scenario

What happens next

  1. The outgoing MA emails success@dwellant.com with the building list, reason and target date.
  2. Dwellant confirms the likely scenario and technical path.
  3. Both MAs provide written authorisation.
  4. The outgoing MA generates the offboarding pack and required exports.
  5. The new MA provides branding, staff/admin details, unit naming and block grouping requirements.
  6. Dwellant schedules and executes the switch.
  7. The new MA spot-checks the building before residents are notified.
  8. Dwellant provides aftercare support for issues raised within the agreed window.

First meeting checklist

Discuss and decide:

  • Which buildings or blocks are moving?
  • Is the new MA already on Dwellant?
  • Has accounting already been synced?
  • Which technical path is likely: Lift & Drop, Clone & Merge, Straight-Up Clone or seeding?
  • What products/data exist: Concierge HV, bespoke portal, compliance, documents, requests, forms, templates, payments, key tags, packages and calendars?
  • What should the outgoing MA export before losing access?
  • What unit naming and block groupings should the new MA use?
  • Which staff/admin users should be added or removed?
  • What branding and menu tiles are required on day one?
  • Should resident communications be suppressed during the switch?
  • Who gives final go/no-go?
  • Who signs off after spot-checks?

HV-specific checks

Where Concierge HV, key tags, packages or concierge badges are in scope:

  • Check staff and HV accounts have moved over correctly.
  • Confirm whether key tags and concierge badges are branded to the old MA.
  • If they are old-MA branded, agree whether they need to be changed to reflect the new MA.
  • Save the uncollected package report before execution.
  • Save the key tag report before execution.
  • If any data is lost, recreated or remapped during the switch, test that QR codes scan correctly under the new building.
  • Confirm whether QR codes or branded tags require remapping, replacement or additional lead time.

Spot-check before residents are notified

The new MA should verify:

  • Correct building and block structure
  • Unit count and naming
  • Staff/admin permissions
  • Resident login access
  • Branding on portal and emails
  • Documents, requests, forms and templates
  • Accounting links where applicable
  • HV staff accounts
  • Packages, key tags, badges and QR-code scans
  • Old MA access removed or restricted as agreed

Need help?

Email success@dwellant.com with the building name, outgoing MA, new MA, target date and whether accounting has already been synced.