💥 Why This Became Critical

This wasn’t a niche issue—it affected every single customer.

Business impact:

• Blocked enterprise onboarding

• Increased churn risk

• High volume of support + data migration requests

Internal workaround:

• Manual scripts by engineering

• Data team handling transfers

• Creating new property records with same name under new customer

None of these scaled.

⚙️ Complexity Behind the Scenes

This change touched nearly every part of the system and required a fundamental rethinking of our underlying architecture. At the core, I worked closely with engineering to define new entity relationships and establish robust data contracts that could support a more flexible, many-to-many model. This foundation became critical, as multiple product teams relied on these updated structures to adapt their own features and workflows.

A significant layer of complexity also came from external integrations. Many of our customers relied on accounting systems like QuickBooks and Vista, each of which operated on different assumptions about how customer-property relationships should be structured. Introducing multiple customers per property disrupted these assumptions, particularly in billing workflows. To address this, we worked closely with the accounting team to redesign our mapping logic, enabling flexible billing across multiple customers while ensuring that all integrations remained stable and fully compatible.

🔄 Migration at Scale

• Impacted 100% of customers

• Designed and implemented migration scripts

• Ensured zero data loss

🚀 Execution & Rollout

We took a phased approach:

• Alpha → Beta → Gradual rollout (2–4 months)

My role:

• Defined PRD and system design

• Aligned cross-functional teams

• Led migration strategy

• Handled customer communication and training

• Collected feedback and iterated

🧠 Reframing the Problem & ⚖️ The Key Decision

At a certain point, it became clear that this wasn’t simply a problem of enabling “ownership change” as a feature—it was a deeper issue with how our system modeled reality. Our data model was fundamentally too rigid to support the dynamic nature of real-world property relationships. Recognizing this, we were faced with a critical decision: either ship a quick workaround that would address the immediate need, or take a step back and re-architect the system properly. The former would save time in the short term but continue to compound technical limitations, while the latter required a significantly larger investment but would unlock long-term scalability. I chose to move forward with the long-term solution, even though it meant committing to approximately 5 months of development and delaying enterprise go-lives, because it was the only approach that truly solved the problem at its core and set the foundation for future growth.

📈 Impact

💼 Business

• Enabled enterprise deal closures

• Prevented churn from high-value customers

• Removed a key adoption blocker

⚙️ Operations

• ↓ 95%+ support tickets related to data transfer

• Eliminated manual scripts and data team interventions

😊 Customer Experience

• Preserved full property history

• Enabled flexible, real-world workflows

• Improved CSAT

🔍 Exploring Solutions

Before committing to a major change, I evaluated multiple approaches:

1. Linked Property Records (Quick Fix)

• Connect old and new properties

Why it failed:

• Fragmented data

• Poor UX

• Didn’t solve root problem

2. UI-Based Data Migration

• Allow users to transfer data between properties

Why it failed:

• High technical complexity

• Risk of data inconsistencies

• Not scalable

🏗️ The Solution

To address the limitations of the existing system, we took a step back and fundamentally redesigned how properties and customers were related to each other. Instead of continuing with a rigid one-to-many structure—where each property could only belong to a single customer—we transitioned to a more flexible many-to-many model. This shift allowed us to better reflect real-world relationships, where multiple stakeholders can be associated with a property at the same time or over its lifecycle.

This new model unlocked several key capabilities:

• 🔁 Multi-Customer Properties
  Properties could now be associated with multiple customers simultaneously, eliminating the need to duplicate records when ownership or management changed.

• 🧾 Customer Roles
  Each customer linked to a property could be assigned a specific role—such as owner, property manager, or contractor—bringing structure and clarity to these relationships.

• 💳 Default Billing Logic
  To maintain consistency in financial workflows, we introduced the concept of a default customer for billing, while still allowing users the flexibility to override this when needed.

• 🔐 Permissions and Control
  To ensure this added flexibility didn’t lead to misuse or confusion, we implemented permission controls where only admins could modify key relationships, such as changing the default customer or adding and removing customer associations.

Together, these changes transformed the system from a rigid hierarchy into a flexible, scalable foundation that could accurately model how properties are managed in the real world.