The short answer

An implementation proposal primarily prices the work the vendor or implementation partner does. It may not fully quantify the internal work your organisation has to absorb, and that work can be substantial, particularly when internal subject-matter experts are heavily involved.

Seven costs sit outside the typical quote: internal staff time, data cleanup, parallel running, the productivity dip after go-live, training beyond the vendor's package, decisions deferred while the project runs, and the exit cost you inherit from the platform you are leaving.

Many of these do not appear on the vendor's initial implementation invoice, which is exactly why they get discovered rather than budgeted.

This is not an argument against migrating. It is an argument for pricing the whole thing before you commit, because a business case built on the quote alone will be incomplete, and the person who signed it will be the one explaining why.

Why does the quote miss so much?

Because a vendor can only price what a vendor controls.

An implementation partner quotes configuration, data migration, testing, training delivery and go-live support. That estimate is usually honest about the scope it covers. The problem is what falls outside it: the hours your controller spends validating migrated balances, the weeks your team spends cleaning ten years of inconsistent vendor records, and the decisions that queue up while your best people are in workshops.

This is not a secret. Oracle's own ERP implementation planning guidance treats internal implementation teams, data cleansing, migration, testing, training and change management as core planning requirements rather than incidentals. The methodology is public. What is less often done is putting a number against the parts of it that your own people perform.

This is different from building the business case for a new platform. A business case asks whether changing systems is financially justified, which we covered in how to build the business case for moving to an ERP. A switching-cost model asks what the transition itself will consume once you have decided to move. The two numbers belong in the same decision, but they answer different questions, and only one of them appears in a vendor proposal.

The practical consequence is that comparing two vendor quotes tells you about two vendors. It tells you considerably less about what the project will cost.

The seven unquoted costs

Read that list and notice the pattern. Most are costs you pay in your own currency: your people's time, your operational throughput, your attention. That is precisely why they escape a budget line, and why the finance function is often the last to see them.

Cost one: internal staff time

One of the largest unquoted costs, and one that is easy to underestimate.

The mechanism is straightforward: internal staff are pulled onto the project alongside their normal duties, the workload becomes heavier than planned, and the project either slows or external consultants are added to keep it moving. Both outcomes cost money, and only the second generates an invoice.

Property migrations concentrate this on specific people. Your controller validates migrated balances. Your lease administrator verifies abstracted terms against original documents. Whoever owns the chart of accounts translates the old dimensional structure into the new one. These are not junior tasks and they cannot easily be delegated, because the point is that someone who knows the data is checking it.

A workable approach is to cost internal hours the way you would cost a consultant's. For example, if your controller spends a day a week for six months, that is roughly 26 days of a senior finance resource, and it is a real number even though nobody bills you for it.

Cost two: data cleanup

The cost that scopes itself after the quote is signed.

A migration proposal typically prices moving your data. It rarely prices fixing it, because nobody has looked at it yet. Then extraction begins and the state of the data becomes visible: duplicate vendor records, inconsistent unit naming, historical entries nobody can explain, lease terms that live in a PDF rather than a field.

Property has particular structures that resist clean migration, and each carries its own cleanup burden:

• Historical CAM and recovery calculations, particularly where supporting detail must remain reconstructable after migration.

• Trust, security deposit and other restricted-fund records, where balances and supporting history may need to remain traceable after the move.

• Recurring charge schedules with future-dated escalations, which are forward logic rather than historical records.

• Chart of accounts translation, where property, unit, entity and department must be reconstructed as dimensions rather than lifted across.

The honest way to handle this is to require data discovery before the quote, not after. An implementation estimate produced without anyone examining your actual data is a guess wearing a spreadsheet, and treating it as a commitment is how the first overrun conversation starts.

Cost three: parallel running

The safety net that everyone approves and few people budget.

Running old and new systems simultaneously around cutover is sound practice. It catches configuration errors and migration gaps before they reach financial statements. It is also expensive in a way that is easy to overlook, because transactions may need to be entered, reconciled or validated across both environments, and your most experienced people spend their time doing it.

Parallel running is often used around cutover, with the appropriate duration depending on your close cycle, risk tolerance, data complexity and rollback requirements. For a property business, a more useful planning measure than weeks is the number of month-end close cycles you need to reconcile across both systems before switching off the old one. How many that should be depends on your close process, data complexity, risk tolerance and rollback plan. For the operational side of planning that period, see our property management software transition tips.

The trap is assuming parallel running is a technical overlap. It is dual operation, and it should be costed as a temporary increase in workload for the duration, whether or not you actually hire.

Cost four: the productivity dip

The cost most business cases assume away entirely.

Productivity can fall during the transition, particularly immediately after go-live, as people learn new workflows, reports are rebuilt, and data or configuration issues surface in live operations. The exact impact varies significantly by organisation, so it is better treated as a project-specific risk to be modelled than as a universal percentage.

The period immediately following go-live matters most, because transaction volumes, reporting cycles and real-world exceptions begin testing the new configuration in ways that testing environments do not. Property has a specific version of this: the month-end close is likely to take longer during the first few cycles. People are learning where things are, reports need rebuilding, and reconciliations that took an hour take a morning.

The practical implication is scheduling rather than budgeting. Going live immediately before budget season, an audit or a reporting deadline puts the disruption exactly where you can least absorb it.

Cost five: training beyond the package

The vendor's training hours produce familiarity. Proficiency costs more.

Standard implementation packages include end-user training on core workflows. What they do not typically include is the deeper work that determines whether the platform is used well: developing internal power users who can configure and troubleshoot, and writing procedure documentation that reflects your workflows rather than the vendor's generic ones.

Developing internal power users matters because proficiency cannot end with vendor-led training. Someone inside the organisation still needs to understand the configured workflows, troubleshoot common issues and support future changes. If nobody internally can configure the system, every future change becomes a paid change request, which converts a one-time cost into a permanent one.

The question to ask during evaluation, not after, is who can configure this after go-live. Our guide to how to evaluate property management software covers the selection criteria, and this question belongs in the cost model as well as the scorecard.

Cost six: deferred decisions

The cost nobody can invoice, because it consists of things that did not happen.

While a migration runs, your senior finance and operations people are partly unavailable. Analysis gets postponed. A pricing review slips. A vendor renegotiation waits. An acquisition workstream moves slower. None of that appears anywhere, and it is genuinely difficult to quantify.

But it can be surfaced, and surfacing it is most of the value. Before the project starts, ask each function what it would otherwise be doing in that period. Write the list down. You will not put a number against most of it, and you do not need to. The list itself changes how leadership scopes the timeline, because a twelve-month project reads differently when everyone can see what waits twelve months.

Cost seven: the exit cost from your current platform

The cost decided years ago, by a contract nobody has reread.

Leaving a platform involves extracting your data, retaining access long enough to answer questions about historical periods, and frequently paying for both systems during overlap. The terms governing all of that were set at signature, often without negotiation, and often by someone who has since left.

Three questions to answer before committing to a timeline:

1. What can you extract, in what format, and at what cost? A tenant list is not an answer. Historical recovery calculations, restricted-fund records and future-dated charge schedules are the test.

2. How long do you retain access after termination? Owner queries and tenant audits can reach back years.

3. What is the notice period, and does it force overlap licensing? This often determines your cutover date more than any technical consideration.

If you are entering a new contract, this is the moment to fix it for next time. Negotiate data portability, audit access and exit provisions before signing, because leverage is at its highest before signature and drops sharply afterwards.

How to build a switching cost model

These six budget lines turn the seven hidden costs into a working model, because some of them group naturally together.

There is no universal contingency percentage that can reliably price these costs. The more defensible approach is to calculate internal staff time, data cleanup, parallel running, productivity impact and exit costs separately for your own project, which is what the six lines above are for.

Two rules make this model useful rather than decorative. Build it before vendor selection rather than after, so it informs the decision instead of justifying it. And show it to the person who will be accountable for the budget, at the point where they can still say no.

The point is not to make migration look expensive. It is that a migration priced honestly and approved anyway is a fundamentally different project from one priced optimistically and revised twice. The second is where budget conversations turn adversarial and projects lose sponsorship.

Where switching costs surface

Frequently asked questions

Q1. What are the hidden costs of switching property management software?
Internal staff time, data cleanup, parallel running, the post-go-live productivity dip, training beyond the vendor package, deferred business decisions, and extraction and overlap costs from your current platform. Most do not appear on the initial implementation invoice.

Q2. How much should you budget beyond the implementation quote?
There is no universal percentage. The more reliable approach is to cost internal staff time, data cleanup, parallel running, productivity impact and exit costs as separate line items based on your own portfolio, data quality, staffing and implementation scope.

Q3. How long should you run two systems in parallel?
It depends on your close cycle, data complexity, risk tolerance and rollback plan. In property the more useful measure is the number of month-end close cycles you need reconciled across both systems, rather than a number of weeks.

Q4. Does productivity really fall after go-live?
It can, and some disruption is normal during a major system transition. People are learning new workflows, reports and reconciliations change, and configuration or data issues surface once real transactions begin. The impact varies, so model it against your own close cycles, transaction volumes and staffing rather than assuming a percentage.

Q5. Why do implementation costs exceed the quote?
Typical sources of variance include requirements discovered during the project, data quality remediation, additional integrations or technology, scope changes, and internal effort not fully accounted for in the original plan.

Q6. What data is hardest to migrate in property software?
Historical CAM and recovery calculations, restricted-fund records such as trust and security deposit balances, recurring charge schedules with future-dated escalations, and chart of accounts translation. Each carries logic rather than just records.

Q7. Should you negotiate exit terms before signing?
Yes. Data portability, audit access and exit provisions are far easier to secure before signature than after implementation, and they determine what a future migration will cost you.

Q8. Is it ever cheaper to stay?
Often, at least in the short term. If your entity structure, asset mix and reporting obligations have not changed, the switching cost may exceed the benefit.

The real cost question

Software decisions get made on a comparison of quotes, which is the one comparison that reliably misleads. Two vendors quoting similar numbers can produce projects that differ substantially, because much of the difference lives on your side of the ledger rather than theirs.

The honest version of the question is not what will the vendor charge. It is what will this cost us, in money, in time, and in the things we will not do this year because we are doing this instead.

Answer that and the decision gets easier in both directions. Some migrations look worse and should not proceed. Others survive an honest number and proceed with a budget that holds, sponsorship that lasts, and nobody explaining a variance in month seven.

The same principle applies to the platform you choose: look beyond the implementation quote and understand the operating model underneath it. RIOO brings property operations and financial management together within NetSuite. See how the platform is structured.