So you’ve heard the pitches, evaluated the options, and identified a promising new technology. You ran comparisons, completed a pilot, and successfully aligned internal stakeholders around the decision. On paper, the results look strong — the technology works, the business case makes sense, and the contract is signed. And often that’s when the real work begins.
Even seasoned real estate executives often find that integrating new technology into an existing portfolio is far more complex than its selection. Organizations are adopting new tools at an unprecedented pace, yet across asset classes and operating models, a consistent pattern emerges: technologies rarely succeed or fail based on features alone. Instead, outcomes hinge on whether a system can integrate cleanly with existing platforms, scale across diverse properties, and win confidence over time throughout the organization.
To better understand how this post-pilot phase plays out in practice, we surveyed members of Insights by Blueprint’s advisory board and conducted follow-up conversations with operators across the broader Blueprint community. These discussions focused less on product evaluation and more on what happens after a solution is approved — when integration, change management, and operational realities take center stage. Key findings from the survey include:
- Most owners and operators are actively piloting new technologies, often multiple times per year.
- Integration challenges — not product performance — are the most common reason technologies fail to scale.
- Pilot integrations are frequently lightweight, with the most complex work deferred until full deployment.
- Data synchronization, workflow conflicts, and organizational alignment are the most persistent barriers.
- Integration readiness is increasingly viewed as a defining factor in long-term proptech value.
Innovation as an Ongoing Operational Muscle
The survey respondents were largely drawn from the c-level of multifamily owners and operators, and most indicated that they integrate new technology multiple times per year, such that integration activities are no longer an occasional IT project — they are an ongoing process built into operations. They increasingly view technology and integration as a core layer rather than an experimental add-on.
At the same time, most organizations are operating in environments shaped by years of incremental technology adoption. Systems implemented at different times, under different assumptions, and with varying levels of integration maturity now coexist within the same portfolios. As a result, integration complexity is compounding — not declining.
Multifamily portfolios, in particular, feel this pressure acutely. Because resident data, access control, leasing, maintenance, and billing systems are tightly interconnected, even small integration gaps can create outsized operational impact.
As a result, organizations are asking questions about integrations very early in the process.
“The very first thing I ask a partner is: ‘What’s your package? What needs to be loaded into our environment?’” says Unified Residential’s VP Dalia Kalgreen. “That’s usually the longest part of the process. Once I have that, I can get instructions to our integration person so they can start, and then I figure out ‘What I can build on the back end while we’re waiting?’”
She said she asks for a tech company’s entire roadmap upfront — including timelines, steps involved, who needs to be involved from a technical standpoint, and what training looks like.
“I want to know exactly what this will mean for our on-site teams,” says Kalgreen. “I also don’t like demos. I want to see real clients. Who actually uses this product, and what does that look like? I ask for references so I can call them directly.”
Seth Siegler, the Chief Innovation Officer at eXp, says integration requirements are among the very first questions his team asks: “Many startups don’t think about APIs early — they’re focused on users and iterating on their MVP. Integration usually comes later. But for us, it has to be up front. If it’s third-party tech — or really any tech — the first challenge is whether it even has an API, and whether it provides the level of access we need. The big question is whether integrating it will create unscalable manual work. We’ve made that mistake before — adopting tools that ended up burying accounting, broker operations, or another team in manual processes.”
Piloting With Purpose
During pilot programs, survey respondents said, integration responsibility is typically shared between vendors and internal teams, with vendors often doing most of the initial setup. This approach lowers friction and accelerates evaluation — but it also often shapes what gets tested.
In many cases, pilots:
- Connect only a subset of available data
- Rely on manual processes behind the scenes
- Avoid edge cases that complicate automation
This makes pilots effective for validating functionality and user experience, but less effective for stress-testing real operational conditions. As a result, technologies that perform well in pilots may still struggle when exposed to the complexity of portfolio-wide deployment.
“We’re very big on extended pilot periods,” says Kalgreen. “Some vendors only want to give you 30 or 60 days, and that’s just not enough to properly pilot new technology. I typically ask for three to six months, and that’s worked well. In one recent case, we were on a 30-day, month-to-month agreement — not even what I’d consider a real contract. The biggest issue was communication. I met with one person, loved the product, and asked all the right questions: Do you integrate properly with Yardi? They said yes. But when we went to implement, I found out they didn’t actually integrate with Yardi at all. What they meant by ‘integration’ was front-end user access, not a true back-end integration. Those are not the same thing, and it caused a big issue.”
For a pilot to be an effective test, it may also need to consume considerable operational resources. Durst’s Director of Digital Mark Domino says that his team tends to be very conservative when it comes to launching pilots.
“Instead of traditional pilots, we spend a lot of time upfront discussing integration complexity with vendors,” says Domino. “When we go into contract, our legal process is very thorough. We typically include performance milestones in our agreements so that if a vendor can’t deliver on an integration they promised upfront, we have mechanisms like fee adjustments or billing clawbacks. Rather than piloting, we rely more on performance-based agreements. Once we make a decision, we build a number of safety mechanisms into the vendor agreement and then move forward fairly decisively. There’s not really a pilot phase—just a series of milestones. As each milestone is cleared, the agreement effectively “ripens” to its full scope. We also include strong cancellation-at-will provisions so that if things don’t work out, we can exit.”
Creating a Structure for Integration with the “Mothership”
Respondents pointed to organization and structure as being key for making sure integrations will work. Putting a formalized process in place, with a timeline, milestones and expectations to guide the process will help to orchestrate all of the tasks needed for a full deployment.
“[Any integration initiative] must have structure,” says BXP’s SVP & CTO Jim Whalen. “I’ll give you an example. We did a pilot with Swift Connect and it went very well and so we said, ‘Okay, we’re going to blow out the enablement and required integrations across 10 million square feet.’ And we put a project management structure in place with both executive sponsors and the team members that meet every two weeks. Calls can take 15 to 30 minutes, but we literally block-and-tackle the work and issues with all the parties focused on achieving the goals. So we got to 10 million square feet in five months, and now the call had morphed into blocking-and-tackling client activations. Sponsorship is key — having the right executive sponsors on both ends with both organizations fully committed. When you’re dealing with a prop tech initiative that touches many properties, effective orchestration across parties is really critical.”
Some of this orchestration revolves around ensuring a fit with core tech, like a PMS, that for many companies is so central to their operations that new additions need to be able to communicate with it.
“I call [Yardi] the mothership,” says Kalgreen. “That’s where all the truth lives — especially for accounting. Everything else gets built around it. But everything must talk to Yardi, specifically Yardi Voyager. Now I’m much more precise in how I ask integration questions: Is this a front-end or back-end integration? Do you have APIs in place? If you don’t have a single source of truth, that’s another red flag — because your data integrity is compromised. … We have just one person who can do Yardi integrations, and she’s overloaded. That can absolutely stall things. But if delays are on the vendor’s side — if they can’t get their ducks in a row — that’s a huge red flag.”
Siegler says that his tech stack is a little more agile, combining lots of different solutions, but that integrations still need structure.
“We’ve always followed more of a best-of-breed strategy rather than an all-in-one platform approach,” notes Siegler. “Because of that, integrations have always been part of how we operate. It usually starts with single sign-on (SSO), which at least gives us a unified login experience. That makes onboarding and offboarding agents much easier as people come and go, or opt into certain tools. From a data standpoint, we also have a centralized data lake strategy. We have a team that syncs data from most systems into the data lake and normalizes it through ETL processes. What’s really changed recently, though, is that we’re building a lot more software in-house — and much faster — because of AI-assisted and “vibe” coding. That’s been a bit of a revolution here. We now have hundreds of non-technical people building their own small point solutions. The upside is speed, but it’s also increased the integration challenge because there are many more, smaller, more specialized tools that all need to flow downstream into our broader ecosystem.”
But even when a structure is required, it doesn’t always need to be the same from project to project. Different models emerge depending on the tech that is being integrated.
“Sometimes we have a consultant that’s doing an integration for us,” notes Whalen. “For example, we’ve moved our entire earnings model to a cloud-based solution with a more complex and demanding data model requiring new tools and services. The project required a partnership with a highly expert team on their side coupled with our internal data team to orchestrate effective integration. But other times we just drive it, for example if the public API is available, we’ll consume the API. And we’ll drive improvements to APIs with our partners based on our needs. The maturity of APIs can vary greatly across solution providers.”
Where Integrations Break Down
Respondents consistently pointed to a small number of recurring integration challenges.
Data synchronization issues — especially around move-ins, move-outs, and permissions — are the most common pain point. When systems fall out of sync, the impact is immediate and visible to both staff and residents.
Workflow conflicts are another major issue. Tools often assume different processes or ownership models, forcing teams to adapt their workflows — or create workarounds — rather than gaining efficiency. So it’s key to communicate effectively with the partner around the workflows that need to happen.
“Outside of the core integration piece, the rest is usually on me to build with the partner,” says Kalgreen. “So I clear my calendar and make sure I have the time and space to do the work.We work hand in hand. That’s very important to me. I don’t like situations where you’re sold something and then handed off to a completely different department that doesn’t understand what was promised. Then you’re trying to integrate something that doesn’t quite work.”
API limitations and uneven documentation can also slow progress. While most vendors market themselves as integration-friendly, operators report wide variation in real-world API depth and support.
“Integration issues often don’t fully surface until a system is deployed, and change management is extremely difficult,” says Domino. “Even if a solution meets early criteria, it can take a long time to unwind once adoption has begun. That’s one of the hardest parts for enterprise organizations.”
When these issues aren’t resolved, the burden shifts to site-level staff, who compensate through manual intervention. Over time, this erodes confidence in new tools and reduces their perceived value.
Why Scale Is Harder Than the Pilot
When asked why successful pilots fail to scale, respondents rarely blamed the technology itself. Instead, they pointed to organizational and structural barriers.
Budget constraints often emerge once integration costs become clearer. Procurement and contracting complexity can slow rollout across large or fragmented portfolios. Portfolio variability — from building age to connectivity — limits standardization. And leadership alignment can lag even when site-level results are positive.
The result is a familiar pattern: a technology works, stakeholders like it, but deployment stalls due to factors outside the product itself.
For owners and operators, the findings suggest a shift in how PropTech should be evaluated. Success increasingly depends on how well a system integrates into existing workflows, data models, and governance structures—not just on features or pilot performance.
For vendors, integration is no longer a supporting function. It is central to product differentiation, customer retention, and long-term adoption.
And for the industry as a whole, the survey reinforces a broader trend: the real challenge in PropTech adoption has moved downstream. The future winners will be technologies—and organizations—that treat integration as a core competency rather than an afterthought.
Integrations in the Current Market Landscape
One clear takeaway from the survey is that the gap between piloting and scaling proptech is not driven by lack of innovation or willingness to adopt. It is more often driven by the complexity of integration in real operating environments.
What’s reassuring is that the rise of AI is now starting to help make many types of integrations less complex, says Siegler.
“API integrations used to sound intimidating, but they’re much less scary now,” said Siegler. “Data mapping and API work have become far more trivial than they used to be. We recently went through a major change for our international division — everything outside North America. That’s 26 countries. Previously, we had a single back-office CRM and website provider globally. We migrated away from that and allowed each country leader to choose the best in-country CRM. That meant we suddenly had 26 different CRMs to normalize and integrate just to create a unified set of listings. Outside the U.S., there’s no MLS — listings originate in the company back-office CRM. With AI, we were able to normalize and integrate all of those systems in a matter of weeks.”
Domino says that the current market landscape is providing a good opportunity to audit and prune Durst’s tech stack.
“We’re looking at consolidation, and changeovers, or eliminating redundancies,” says Domino. “I’ve also been trying to cultivate a more deliberate “tech stack” perspective across different divisions. That means maintaining an inventory of tools, understanding what each one does, how they communicate, and where there might be risks—such as end-of-life events. That could mean the end of a contract, an acquisition, or a product being sunset.”
As portfolios become more connected and expectations for automation rise, integration readiness will increasingly determine which technologies deliver lasting impact — and which remain stuck in pilot mode.
-David Hirschman
