Global Search
Micro-Frontend Tenancy Migration
Problem
Global Search ran inside a shared enterprise micro-frontend, mounted on another team's root module. Its release lifecycle, configuration, and integration ownership were coupled to that host. The host also controlled client-side script execution, which left an analytics gap in the first seconds after page load.
Constraints
- Search was coupled to a shared enterprise MFE root module.
- Release and configuration ownership sat with the host team, not with Search.
- The existing user-facing Search URL had to stay unchanged.
- Analytics, experimentation, feedback, and chatbot integrations had to keep working across the move.
- Analytics behavior had to remain correct through the cutover.
Architecture
shared enterprise OneApp MFE
↓
Search coupled to shared root
↓
dedicated Search OneApp MFE
↓
Akamai rewrite behind existing user-facing URL
↓
independent release / configuration / analytics ownershipArchitecture & approach
Led the frontend architecture and migration strategy for Global Search, driving the transition from a shared enterprise Search frontend to independently owned OneApp MFE tenancy. The dedicated-tenancy direction came from technical SMEs and Staff Engineering; I owned turning it into an executable migration — designing the new root module, mapping runtime dependencies, and sequencing the cutover across teams. The new model established a dedicated OneApp MFE and root module with independent ownership of configuration, releases, and integrations.
Routing transition
Drove the implementation of an Akamai rewrite that placed the new MFE behind the existing user-facing URL without a browser redirect, preserving the established user experience. The network team implemented the Akamai configuration itself; I designed the rewrite behavior and owned how the new tenancy sat behind the unchanged public URL.
Integrations
Coordinated the migration of analytics, experimentation, feedback, and chatbot integrations while preserving existing behavior across the new tenancy boundary.
Analytics correctness
Diagnosed an approximately 10-second analytics blind spot caused by client-side script execution order in the previous host: Search analytics scripts could run after other host scripts, so early interactions after page load were not captured. Drove the fix by reworking script execution order across analytics and experimentation integrations, closing the gap.
Outcome & Lessons
- Search owns its release lifecycle, configuration, and deployment boundaries independently of the previous host.
- Eliminated the approximately 10-second analytics blind spot by reworking client-side script execution order across analytics and experimentation integrations.
- Owned production rollout and post-release validation, resolving integration and behavioral issues as the new tenancy was introduced.
- Authored migration guidelines and provided technical direction to engineers adopting the new tenancy architecture.
- Lesson: tenancy boundaries decide who owns releases, configuration, and production behavior — not just where the UI is mounted.