Reshaping Platform Migration Strategy
I was brought in to assess how a new entity management system would affect Sightline's deliverable creation flow. The further I got into the problem, the clearer it became that the UI question was the wrong question entirely.
PwC Tax was consolidating legal entity data across its entire product suite into a single system. Sightline was one of many downstream consumers that would need to adapt, yet nobody had mapped what that would actually require.
Background
Sightline is PwC's internal platform for managing tax engagements. PwC preparers and reviewers use it to track deliverables, manage client data, and coordinate the filing work across an engagement. Client stakeholders use it to review progress and provide information.
At the center of all of that work is the legal entity — the corporate structure a client files taxes under. Every deliverable in Sightline is tied to one. The entity determines taxation method, statutory deadlines, record uniqueness, and reporting accuracy. Getting it wrong has downstream consequences across the entire engagement.
Entity data was central enough to the work that a shared infrastructure seemed like a given. It wasn't. Each tool in the PwC Tax suite maintained its own records independently. The result was conflicting records, inconsistent metadata, and manual reconciliation whenever work crossed product boundaries.
A single centralized entity layer, shared across all tools in the PwC Tax suite.
Each product maintained its own entity records independently, with no shared standards or governance.
Enter Entity Ops
Entity Ops was PwC Tax's answer: a centralized product designed to become the single source of truth for legal entity data across the suite. The value was clear. What hadn't been worked out was how to get there from where things actually stood.
"Consolidate legal entity data into a reliable single source of truth."
pwc.com, Entity Ops
The problem
Entity Ops was being positioned as the future home of all legal entity data across PwC Tax. For Sightline Deliverables, that meant a fundamental change to how entity creation worked. A workflow that had always lived inside Sightline would now route through an external system.
As the lead designer on Sightline Deliverables, I owned the design work required to adapt the app to that new reality. The immediate questions were practical: what entity metadata did Sightline actually need, how would entity creation change for preparers, and what were the technical integration requirements?
Those questions turned out to be harder to answer than expected. Not because Sightline was complex, but because the Entity Ops integration hadn't been fully defined yet. The closer I looked, the more gaps appeared.
My role
On the Sightline side, I owned the integration work between Sightline Deliverables and Entity Ops.
As the project developed, my manager asked me to support a junior designer on the Entity Ops side. I joined planning meetings with the designer and PM to help translate design requirements into clear direction and keep delivery on track.
Working both sides put me in an unusual position. I could see how decisions made in Entity Ops landed in Sightline, and how assumptions on each side didn't account for what the other was planning. That visibility is what eventually surfaced the larger problem.
Process
My starting point was straightforward: understand what Sightline Deliverables needed from Entity Ops and design the changes to support it. I began by mapping the existing deliverable creation flow to identify where entity data touched it and what a preparer's experience would look like once entity creation moved to an external system.
Finalizing the Sightline flow
That mapping work surfaced the first round of practical questions:
- How would Sightline receive entity data from Entity Ops?
- Would creation still be possible from within the app, or would preparers need to leave Sightline entirely?
- What happened if an entity existed in Entity Ops but hadn't been pushed to Sightline yet?
To get answers, I started joining integration calls with business analysts and engineers on the Entity Ops side. Those conversations gave me enough to produce a finalized happy path of the ideal deliverable creation flow, assuming the required entity data was already in the system and available.
Entity Ops creation flow
When I moved to supporting the junior designer on the Entity Ops side, I got a direct view into how the entity creation process was being designed. The wizard flow needed to accommodate data requirements from multiple downstream apps, each with their own metadata needs, while keeping the creation process intentional enough that users understood the weight of what they were creating. Entity data, once in the system, would flow across the entire suite.
The pivot
The further I got into the integration work, the more I noticed something missing from the conversation. Every question I was asking assumed that existing entity data across PwC Tax products would be accounted for. The Entity Ops team was designing for a clean system.
Beginning where I originally started working, I mapped out the entity creation steps from the moment a user initiates a new deliverable in Sightline. Analyzing where the flow might break down, I found three gaps the integration team could design around. The fourth was different.
The reality was that years of entity records, created across multiple tools with inconsistent metadata and no shared standards, would need to go somewhere.
The flow had no answer for existing entity data
-
01
Creation via API was not possible
-
02
Entities may need approval before usage
-
03
Data may not automatically sync to Sightline
-
04
No plan for migrating existing entity data
What nobody had addressed was the existing entity data — the records tax teams were actively using across every product in the suite.
The question was no longer how Sightline should adapt its UI. It was how the platform would migrate to Entity Ops without breaking the data underneath it.
The solution
With the migration gap identified, I worked with a product manager and a UX researcher to map out what a safe transition to Entity Ops could look like. We developed three approaches, each trying to answer the same question: how do you centralize years of fragmented entity data without introducing new integrity risks in the process?
Option A — Centralized Migration
Entity Ops ingests data from all existing apps, normalizes and deduplicates it, flags conflicts, and downstream apps consume the cleaned result.
The result: clear ownership over data cleanup, with reduced burden on downstream product teams. The tradeoff is significant upfront effort and slower time to first release.
-
01
Entity Ops ingests data from all legacy apps
-
02
Data is normalized and deduplicated
-
03
Conflicts are flagged and reprocessed until resolved
-
04
Cleaned data is distributed to migrated apps
Option B — Distributed Reconciliation
Each product team migrates independently, ingesting from the most reliable existing source and reconciling with Entity Ops.
The result: faster rollout and lower initial burden on the Entity Ops team. The tradeoff is that migration effort gets duplicated across every app, and the burden shifts to product teams and tax staff who are already busy.
-
01
Entity Ops seeds initial data from the most reliable legacy source
-
02
Each app independently ingests, normalizes, and reconciles its own records
-
03
Conflicts are flagged and reprocessed within each app
-
04
Net new data is pushed back to Entity Ops
-
05
Migrated apps consume the reconciled data
Option C — Phased Migration
Migration happens client by client, starting with a pilot. Data is collected, cleaned, and reconciled before downstream apps test the integration.
The result: slower full adoption and some short-term complexity from running parallel systems. But it reduces the risk of conflicting data and allows the process to improve before it scales.
-
01
A pilot client dataset is selected to begin migration
-
02
Data is ingested, normalized, and deduplicated within Entity Ops
-
03
Conflicts are flagged and reprocessed until resolved
-
04
Migrated apps come online for that client
-
05
Process repeats client by client before full rollout
Evaluation
Each approach was weighed against the same underlying tension: data integrity risk against speed of adoption. The differences came down to who took on the migration burden and at what point in the process.
Centralized Migration
Strengths
- Clear ownership of data clean-up
- Reduced burden on downstream product teams
Tradeoffs
- Significant upfront data clean-up effort
- High coordination across teams
- Slower time for first release
Distributed Reconciliation
Strengths
- Faster Entity Ops roll-out
- Product teams migrate independently
- Lower initial burden on Entity Ops team
Tradeoffs
- Increases burden on product or tax teams
- Duplicates migration efforts across apps
- Effort spent creating migration tooling
Phased Migration
Strengths
- Reduces risk of conflicting data
- Allows for improvements to migration process
- Balances speed with data quality
Tradeoffs
- Slower full adoption of Entity Ops
- Temporary parallel systems during transition
- Some short-term product-level complexity
My recommendation: Option C.
The first two options both front-loaded risk in different directions. Option A placed a heavy coordination burden on the Entity Ops team before anything could ship. Option B distributed that burden across every downstream product team with no guarantee of consistency.
Option C accepted a slower path in exchange for the ability to catch and correct problems before they reached the entire platform. The long-term benefit of centralizing entity data was never in question. Rushing the migration was.
Outcomes
Before this project, nobody had formally mapped what migrating 80,000+ legal entities across an active platform would actually require. The structural risks hadn't been named, and no migration strategy existed. This work changed that.
The three options and their tradeoffs gave stakeholders a framework for a decision that hadn't been formally scoped yet. A formal implementation plan was never kicked off. Shortly after, PwC Tax began a round of layoffs and the Entity Ops initiative was paused. But the value of the work was never in shipping a migration. It was in making sure the right questions were on the table before anyone committed to a direction.
Reflections
What I'd do differently
I trusted that with so many people working across the integration, the bigger structural questions were being handled, but they weren't. If I were working on this again, I'd challenge that assumption earlier and escalate concerns sooner, even when the finding isn't fully formed yet.
What this reinforced
Asking the obvious question is sometimes the most valuable thing a designer can do. Being embedded across both sides of the integration put me in a position to see something that hadn't been formally named yet. That question changed the scope of the work.
Thanks to Doug Hoover, Bryce Newberry, Sam Moore, and Jennifer Jennings for their collaboration on this project.
Back to work