Switching Building Management Software: What Week One Actually Looks Like

Switching building management software costs a building roughly one working week of real effort before residents see anything, and most of that week is data rather than software. URBI is built so that week stays short. Here is what actually happens, including the parts nobody enjoys.

Every vendor page jumps from "book a demo" to "you are live". The middle is where buildings hesitate, and nobody writes it down. Here it is.

What do you need in hand before week one starts?

Six things, five of them inside the system you are leaving.

• The unit list. Every unit, numbered exactly the way the building uses it.
• The owner and resident roster. Name, unit, email, mobile, and whether each person is an owner, resident, tenant, or dependent.
• Current documents. Bylaws, rules, AGM minutes, fire safety plan, reserve fund summary, insurance certificates, contracts.
• Open work orders. Anything not closed on the day you switch, plus whatever history you can get.
• Amenity rules as actually enforced today. Booking windows, deposits, notice periods, who may book what.
• The admin login for the current system, held by someone who still works there.

The export is the long pole. Some vendors hand you clean CSV files the same week you ask. Others hand you a stack of PDF reports and answer email slowly. That is the difference between a one week migration and a six week one. Ask for the export before you sign anything new, in writing, naming which record types are included.

Do not assume the new vendor does the cleaning. Panorama Consulting Group notes that "most ERP vendors do not take responsibility for data migration or cleansing" in its guidance on data migration and cleansing. That is enterprise software, so treat it as adjacent evidence, but the pattern holds.

Contract timing sinks more switches than any technical problem. Find your notice period and renewal date first. A twelve month term renewing in March means notice goes in during January. Plan for a month of overlap, because you will want the old system readable while you check the new one. Buildings leaving a large incumbent should read our notes on switching from AppFolio.

Check what your state requires you to keep. Florida Statutes section 718.111 requires a condominium association's declaration, bylaws and minutes to be kept permanently, and most other official records for at least seven years, "in an organized manner that facilitates inspection". The association has ten working days to produce records after a written request. States differ, the principle does not. Do not switch off the old system until the archive is out and searchable.

Why does your data look worse the moment you export it?

Because the export shows you what was always in there. A migration does not create bad data. It is the first time anyone reads the whole list.

• The same owner recorded as Smith, Smyth, and S. Smith across three tables.
• The same apartment written as 1201 in the unit list and PH01 in the amenity log.
• Phone numbers that stopped working two board terms ago.
• Residents who moved out two years ago and are still on the notice list.
• Documents named scan_004.pdf that turn out to be the insurance certificate.

None of that is the new platform's fault, and a board reading the import error report as a product defect makes the project harder. The cleanup is real work, worth doing once. A building that cleans its roster during a migration gets a correct roster for the first time in years.

URBI takes messy exports through a CSV import with an AI cleanup step. It handles exports from BuildingLink, RealPage, Yardi and similar, and it fixes format problems: headers that do not match, dates written three ways, phone numbers with and without country codes, unit numbers padded with zeros in one file only.

What it will not do is decide which of two mailing addresses for the same owner is current. Nothing can. That is a judgment call belonging to whoever knows the building. Expect a list of those back, and expect it to take an afternoon.

URBI also does not offer direct two way sync with a property management system, by choice. A one time import you can inspect beats a live connection nobody audits. Run several buildings and the same import path feeds one operator workspace, covered in our piece on multi property management software.

What happens day by day in week one?

Five working days, in this order, with the resident invitation held back until the following week.

Day two is the one buildings underestimate. URBI has three operator role types: staff, Board Member and Property Manager, with staff typed as on site or concierge. Residents come in five occupant types. Per person overrides handle edge cases: a treasurer granted reserve fund detail, a probationary staff member locked out of financial dashboards, no base role changed. Permissions get configured rather than compromised, but somebody has to decide. Book an hour with the board.

Vendors are the pleasant surprise. They get no login at all. Your plumber receives a tokenized work order link by email, schedules the visit, toggles subtasks, and uploads completion photos. There are no vendor accounts to create and no licenses to buy. Most migration plans forget this step entirely and then find it is the longest.

Day four is faster than people expect. Documents sit in three layers: building level for bylaws, minutes and fire safety plans, unit level for leases and paperwork, and a free form wiki per unit. Every PDF is indexed by content on upload, so search works immediately. Nobody retitles four hundred files first.

Amenities carry their rules as settings rather than a policy document you hope residents read. Opening hours, maximum booking length, booking limits, capacity, notice hours, a check in flag, and a rule per occupant type saying who may book each space and whether a surcharge applies. Your existing rules become configuration. That is the conversation part, because somebody has to say out loud what the rules are, and buildings often find they disagree.

For the wider picture before you start, what URBI is and URBI for residential buildings are the places to begin.

How do you invite residents without losing half of them?

Announce before you invite, and give people a reason on day one instead of an app to download. Adoption is where these projects succeed or fail, and it is a communications problem, not a technical one.

Device access is rarely the obstacle. Pew Research Center's survey of 5,022 US adults, conducted from February to June 2025, found 91% of US adults own a smartphone, including 78% of adults 65 and older. Almost everyone in your building can install the app. Whether they want to is the real question.

• Announce about a week ahead. Paper under doors, a lobby notice, and whatever channel residents already read. Say what changes for them in one sentence.
• Lead with a thing they want. Amenity booking and package notifications move people. "Book the party room from your phone" gets installs. "We have a new resident portal" does not.
• Invite on a weekday morning. Evenings and weekends get buried.
• Send exactly one reminder, seven to ten days later. It picks up most of the residents who meant to sign up and forgot. It is the highest value message you send.
• Then stop. A third reminder buys very little and costs goodwill you will want later.

The URBI resident app is a free download on iOS and Android covering thirty two screens, from amenities and packages to board decisions, documents, visitors and service tickets. Bookings sync to the phone calendar and visitor passes render as QR codes. Give residents one of those on day one and the download explains itself.

Now the honest part. Some residents will never sign up, and chasing them wastes a manager's week. Plan around them:

• Keep email working. URBI sends announcements by email as well as push, and a resident replying to a building email lands back in the same operator thread.
• Use the lobby. URBI Display puts news and events on standard lobby and elevator screens, and an emergency takeover overrides every screen in seconds.
• Let Arthur pick up the phone. Each building gets its own number, and Arthur answers by voice, SMS, email and in app chat in ten languages.
• For packages, an acknowledge fallback covers residents with no push, so the chain of custody still records who collected what.

Be suspicious of anyone quoting a signup rate at you. No reliable public benchmark exists for how many residents activate a building app in the first thirty days. RETTC's multifamily technology benchmark draws on 55 technology leaders and sits behind membership, and the figures circulating publicly are vendor case studies measured over two years. Our piece on resident app adoption covers what holds up.

Should you run both systems in parallel or cut over?

Cut over on everything residents touch, and keep the old system as a read only archive with an end date written into the board minutes. Parallel running is safer in theory and expensive in practice.

It gives you a rollback path. It also gives you double entry, and double entry drifts. Amazon Web Services puts it plainly in its migration cutover guidance: "the synchronization of databases to ensure consistent data in both locations can increase complexity". That is general IT guidance, and property specific research here is thin, but the mechanism is the same when the two databases are your ticket queue and your roster.

These must never run in parallel:

• Resident messaging. Two inboxes means residents pick the wrong one and staff answer neither.
• Service tickets. A ticket in two systems is a ticket nobody owns.
• Amenity bookings. Two calendars double book the party room on the first Saturday, and the board hears about it.
• Payments. One system of record.

What can safely run alongside is the historical archive, read only, until the export is verified. If accounting is in scope, run one month end in both and compare before retiring the old ledger. URBI's accounting module is in beta, so sequence around it.

The failure mode is not disaster. It is drift. Nobody sets an end date, the old system stays open just in case, and a year later half the staff still open it every morning. Pick the date at the start and turn off write access on it.

Who actually has to change how they work?

The on site staff, and more than anyone, the person who administered the old system. That person decides whether the new one succeeds. If they were not in the room for the decision, fix that before the import runs.

This is the best evidenced part of the subject. Prosci's 11th edition Best Practices in Change Management study, published in 2020 with 1,863 participants across 85 countries, found active and visible sponsorship to be the single greatest contributor to a change initiative meeting its objectives. Where sponsors were extremely effective, 73% of projects met or exceeded objectives. Where sponsors were very ineffective, 29% did.

Translated to a building: the board president who signed the contract is the sponsor, and signing is not sponsoring. Sponsoring is showing up at the staff session, answering the first complaint in public, and using the system.

• Concierge and front desk. One short session on packages, visitors and tickets. They are on it constantly, so they learn fastest.
• Property manager. Longer. Tickets, recurring maintenance, announcements, documents, permissions, reporting. Expect two sessions and a week of questions.
• Board members. A walkthrough of decisions, voting, and where documents live. They touch the system a few times a month and need it obvious.

HERO, the manager facing AI, is desktop web only. Any enabled user can have it, board members included, but it is not in the mobile app and not available to residents. Say that plainly in training so nobody spends a fortnight looking for it on their phone.

Then there is the board member who liked the old system. They are usually not being difficult, and they are often the one person who knows why a rule is written the way it is. Give them a job. Have them run the first board decision and vote through the new platform, where every vote is logged. The condo board guide to building software covers how to frame that.

Keep the usability bar high, because your staff did not sign up for a software project. Teddy Ho, director of product at AppFolio, told Propmodo in October 2025 that "property managers are not technologists and don't want to be". Hold every platform to that, including ours.

What should be true at thirty, sixty, and ninety days?

Three checkpoints a board can verify without taking anyone's word for it.

The day 90 archive line matters more than it looks. Retention obligations do not transfer to the new vendor. A board that cancelled in month two without exporting finds out during a records request.

What should you check before you commit?

Ask what is missing rather than what is included, because the included list is on every website and the missing list is on none. Here is URBI's:

• No single sign on for operator accounts, and no SCIM provisioning. Accounts are created and removed by hand. Fine for a building with a handful of staff. Raise it early if you have an IT department.
• No published public API. Integrations are handled case by case.
• No direct two way sync with a property management system. CSV import with AI cleanup is the path in.
• No SOC 2 Type II report published. If your board or insurer requires one, that is a real gate and it belongs in the first conversation, not the last.
• Accounting is in beta. Asset management and certificate of insurance tracking are on the roadmap and not shipped.

Plan the switch around that list. Moving a full general ledger on day one means planning against a beta module, and it is better to know that before the board votes. If you are still comparing, the best condo management software and our Condo Control alternatives piece lay out the trade offs.

Why do migrations stall?

Almost never for technical reasons. In the published research, and in every stalled project we have seen, the causes are organizational.

• No internal owner. A vendor cannot own your migration. Somebody at the building has to be accountable by name, with time allocated for it.
• Incomplete data handover. The export arrives with the roster and without the documents, and the project waits on a request nobody chases.
• A board that approved a purchase but not the work. Signing is a decision. Cleaning a roster and agreeing amenity rules is labor, and it has to be scheduled.
• Bad timing. Launching into AGM season, budget season, or late December means the people you need are elsewhere. If your AGM is in six weeks, wait.

The closest solid evidence sits outside property management, so label it adjacent and use it anyway. Panorama Consulting Group's 2026 ERP Report, drawn from 170 organizations surveyed between January 2025 and January 2026, reports roughly a quarter of projects running over schedule, and the most common reason was organizational: governance, resistance to change, process redesign. Fewer than a quarter reported an intense focus on change management. Enterprise timelines do not transfer to a single building. The failure mechanism does.

None of that argues against switching. It argues for treating the switch as a project with a named owner, a date, and a board that stays interested past the signature.

Frequently asked questions

How long does switching building management software actually take?

Plan for one working week of setup and import, a second week for the resident invitation, then about ninety days before the building is fully operating in one place. That is what a prepared building should plan for, not a guarantee. The variable is how fast the incumbent produces a usable export.

Will we lose our history when we switch?

Not if you export before you cancel. Documents, unit records and open work orders come across through the CSV import, and URBI indexes every uploaded PDF by content, so the archive is searchable straight away. Closed ticket history varies by what the incumbent will export. Verify the archive before the old system goes dark.

What happens to residents who never download the app?

They keep getting announcements by email, they see notices on the lobby screens, and they can call or text Arthur on the building's own number in ten languages. Package pickups still record a chain of custody through the concierge. Every building has a group who install nothing. Route around them rather than nag them.

Can we run the old system and URBI at the same time?

Keep the old one readable, but do not operate both. Resident messaging, service tickets, amenity bookings and payments belong in exactly one system from day one, because two of any of those means one is always wrong. Set the date the old system goes read only before you start, and record it in the minutes.

Who should own the migration inside the building?

The person who administered the old system, backed visibly by a board member. Research on change projects puts active sponsorship ahead of every other success factor, and the pattern holds in buildings. If the person who knew the old system best is not part of the decision, the migration will technically finish and practically fail.

If you want a straight answer about what your week one would look like, including the parts of the platform that are not finished, write to us at hello@myurbi.co with your unit count and your current system. We will tell you what the export usually looks like and whether your timing is right. If the answer is to wait until after your AGM, we will say so.