We Can't Stop Shipping Features to Rebuild—How Do You Migrate Architecture While Keeping Velocity?

vp_eng_keisha · March 22, 2026, 5:23pm

We’re at an inflection point.

Our EdTech platform needs to evolve architecturally to support the next phase of growth. The current system is showing strain—performance issues, scaling challenges, feature delivery slowing.

The board understands. The executive team is aligned. We have buy-in to invest in the migration.

But we can’t stop shipping features.

We’re in a competitive market. Customer expectations are high. We have committed roadmap items. Our Series C fundraising narrative depends on continued growth momentum.

So here’s the challenge: How do you migrate your architecture while maintaining feature velocity?

The Constraints We’re Working With

Business Constraints

Can’t afford a “feature freeze” for 2-3 quarters
Investors want to see consistent delivery metrics
Competitive pressure requires continued innovation
Customer commitments must be met

Technical Constraints

Current monolith serves 1M+ users
Can’t have extended downtime
Need to maintain data consistency during migration
Legacy system must remain stable while we build new one

Team Constraints

80 engineers total, can dedicate maybe 20-25 to migration work
Can’t just “hire more people to go faster” (Brooks’s Law)
Existing team needs to maintain deep context on current system
Knowledge transfer to new architecture takes time

The Patterns We’re Considering

We’ve been researching approaches:

1. Strangler Fig Pattern

Gradually replace old system with new
Both run in parallel
Traffic shifts incrementally
Old system eventually “strangled” and retired

Pros: Lower risk, gradual rollout
Cons: Complexity of running two systems, data sync challenges

2. Feature Flags + Canary Deployments

Build new architecture alongside old
Use feature flags to control which users see new vs old
Gradually roll out new implementation
Can roll back instantly if issues

Pros: Fine-grained control, easy rollback
Cons: Code complexity, feature flag management overhead

3. Branch by Abstraction

Create abstraction layer over current implementation
Implement new architecture behind the abstraction
Switch implementations without changing callers
Remove old implementation once fully migrated

Pros: Clean separation, testable in isolation
Cons: Upfront abstraction work, temporary code duplication

The Organizational Challenge

Beyond technical patterns, there’s a team question:

Option A: Dedicated Platform Team

Create a team of 20-25 engineers focused solely on migration
Product teams continue feature development on current system
Platform team builds new architecture

Pros: Focused effort, clear ownership
Cons: Knowledge silos, integration challenges, “us vs them” dynamics

Option B: Distributed Ownership

Every product team owns their domain’s migration
Central architecture group provides guidance and tooling
Migration happens incrementally as teams touch their code

Pros: Domain knowledge preserved, no silos
Cons: Slower progress, inconsistent approaches, coordination overhead

Option C: Hybrid Model

Small platform team builds core infrastructure (auth, data layer, deployment)
Product teams migrate their specific domains
Platform team provides migration tooling and support

Pros: Best of both approaches
Cons: Coordination complexity, unclear boundaries

Measuring Success Without Sacrificing Delivery

How do you track both migrations AND features?

Metrics we’re considering:

Migration Progress

% of traffic running on new architecture
% of features migrated
% of data models moved
Technical debt reduction (incidents, performance)

Feature Delivery

Features shipped per quarter
Velocity trends (story points or similar)
Time to market for new capabilities
Customer-facing value delivered

The fear: Migration metrics look good but feature delivery tanks. Or feature delivery stays high but migration never completes.

The goal: Maintain 80%+ of pre-migration velocity while making consistent migration progress.

The Velocity Question

Here’s what I’m most worried about:

In the first 6 months of migration, how much does velocity typically drop?

I’ve heard ranges from “10% if done well” to “50% initially.”

If we drop to 50% velocity, that’s equivalent to losing 40 engineers. That’s $6M/year in lost feature capacity. Hard to justify even with long-term benefits.

But if we can maintain 80-90% velocity during migration, the business case is clear.

The Product Roadmap Dance

Product leadership is asking:

“Can we still ship the Q2 features while migrating?”
“What about the enterprise tier we promised for Q3?”
“If we commit to this customer, will the migration delay delivery?”

I need to give them answers. But I don’t want to over-promise.

The honest answer is probably: “Most features will take 10-20% longer during migration. Some features might take 50% longer if they touch areas being actively migrated.”

But that’s hard to roadmap with certainty.

What I’m Looking For

For those who’ve migrated architecture without stopping feature delivery:

What patterns worked? Strangler fig? Feature flags? Something else?
How did you organize the team? Dedicated platform team? Distributed ownership?
What velocity impact did you actually see? Not the theory—what happened in practice?
How did you manage product expectations? Did you commit to specific features during migration?
What would you do differently? Knowing what you know now, what would you change?

We have the executive buy-in. We have the budget. We have the motivation.

Now we need the execution strategy that doesn’t sacrifice growth while we evolve.

Would love to hear real stories, not just best practices. What actually worked in practice?

cto_michelle · March 22, 2026, 5:24pm

Strangler fig pattern is the answer. We’ve done this twice now at scale, and it’s the only approach that maintains velocity while migrating.

Real Numbers from Our 18-Month Migration

Context:

100 engineers, mid-stage SaaS
Migrated from Rails monolith to domain-driven services
Maintained 85%+ velocity throughout

What We Did: Strangler Fig + Feature Flags

The pattern:

Build new architecture in parallel - Don’t touch the old system
Create routing layer - Traffic can go to old OR new implementation
Use feature flags - Control which users see which implementation
Migrate domain by domain - Not all at once
Both systems run for months - Old system isn’t shut down until new one is proven

Example: User Authentication Migration

Month 1-2: Build new auth service, deploy it, route 0% traffic
Month 3: Route 5% of auth traffic to new service (internal users, low-risk)
Month 4: Route 25% (feature flag for specific cohort)
Month 5: Route 50% (monitor metrics closely)
Month 6: Route 90% (only legacy integrations stay on old)
Month 7: Route 100%, start deprecation plan for old auth
Month 9: Fully decommission old auth module

The Velocity Impact (Real Numbers)

Pre-migration baseline:

Features shipped per quarter: 35-40
Average cycle time: 3 weeks
Deployment frequency: 15/week

During migration (18 months):

Q1 (Migration start):

Features shipped: 32 (91% of baseline)
Cycle time: 3.2 weeks
Deployment frequency: 14/week

Q2-Q4 (Peak migration):

Features shipped: 28-30 per quarter (80-85% of baseline)
Cycle time: 3.5 weeks
Deployment frequency: 12/week

Q5-Q6 (Completing migration):

Features shipped: 33-36 (94% of baseline)
Cycle time: 2.8 weeks (BETTER than pre-migration)
Deployment frequency: 18/week (BETTER than pre-migration)

Total velocity impact: 15-20% drop at peak, recovered fully by month 12, exceeded baseline by month 18.

Why This Worked

1. Both Systems Run in Parallel

This is critical.

Old system handles production traffic (no risk)
New system gets gradually introduced (learn and iterate)
Can rollback instantly if new system has issues (feature flag flip)
No “big bang” cutover risk

2. Feature Flags Give Control

We used LaunchDarkly but any feature flag system works.

The pattern:

if feature_flag_enabled?(:new_auth_service, user)
  NewAuthService.authenticate(user)
else
  OldAuthModule.authenticate(user)
end

Benefits:

Can target specific users (internal, beta customers, enterprise tier)
Can rollback without deploying code
Can gradually increase percentage
Can monitor metrics per implementation

3. Infrastructure as Code Made This Possible

Both environments existed simultaneously:

Old monolith: legacy infrastructure
New services: containerized, orchestrated

No manual environment management. Everything automated.

4. Clear Success Metrics Per Domain

For each domain migration, we tracked:

Before migration:

Performance baseline (latency, throughput)
Error rate baseline
Cost baseline (infrastructure)

During migration (old vs new comparison):

New system must meet or exceed performance
New system error rate must be ≤ old system
New system cost must be ≤ old system (or have clear reason)

Only migrate traffic when new system meets all criteria.

The Team Organization

We did Option C: Hybrid Model

Platform team (8 engineers):

Built core infrastructure (service mesh, auth framework, data migration tooling)
Created migration playbooks and templates
Provided support to product teams

Product teams (remaining ~70 engineers):

Each team owned migration of their domain
Used platform team’s tooling and guidance
Maintained feature velocity on whichever system they were using

Why hybrid worked:

Platform team prevented “every team solves the same problem differently”
Product teams preserved domain knowledge
No knowledge silos between “old” and “new” engineers
Coordination overhead manageable

The Product Roadmap Strategy

What we told product leadership:

“For the next 18 months, feature delivery will be 80-85% of normal pace. But features on the new architecture will ship 30% faster once migration is complete. The investment pays back within 24 months.”

What we committed to:

Critical customer commitments: YES (we’ll prioritize)
Experimental features: MAYBE (depends on migration timeline)
Technical improvements that depend on new architecture: AFTER migration

What actually happened:

We met 90% of committed features (some slipped but not many)
We delayed some “nice to have” features
Customers noticed zero impact (we didn’t tell them about the migration)

What I’d Do Differently

Start earlier: We waited too long (sound familiar from earlier threads?)

Invest more in monitoring: We should have had better observability from day one

Clear communication: Over-communicate progress to stakeholders

Celebrate milestones: When a domain fully migrates, celebrate it

Accept temporary code duplication: We tried too hard to DRY between old and new. Just accept duplication during transition.

Your Velocity Question

In the first 6 months of migration, how much does velocity typically drop?

With strangler fig pattern: 15-20% drop is realistic.

Without it (big bang rewrite): 50%+ drop, or complete stoppage.

15-20% is manageable. That’s the difference between shipping 35 features and shipping 28 features per quarter.

For 80 engineers at $150K average, that’s ~$2.4M in annual lost productivity. Over 18 months: $3.6M.

But compare that to David’s $2.3M cost of delay, or Maya’s startup failure. It’s worth it.

The Answer to Your Question

Yes, you can migrate architecture while maintaining velocity.

Use strangler fig pattern. Use feature flags. Run both systems in parallel. Migrate incrementally.

You’ll take a 15-20% velocity hit. But you’ll complete the migration. And velocity will recover and exceed baseline.

The alternative—waiting until you have time for a “proper” migration—means you never do it.

eng_director_luis · March 22, 2026, 5:25pm

Michelle’s strangler fig approach is exactly what we did in financial services. Let me add the specific patterns that made it work.

The Feature Flag Strategy That Maintained Velocity

The key insight: Feature flags let you deploy new architecture without exposing it to users.

This means:

Engineering can move fast (deploy to production daily)
Product can move cautiously (control user exposure)
Risk is minimized (instant rollback if needed)

Our Feature Flag Hierarchy

We used three levels:

Level 1: Infrastructure Flags (Engineering-Controlled)

new_auth_service_enabled: false
new_billing_service_enabled: false
new_reporting_service_enabled: false

These control whether new services are deployed at all. Engineers flip these.

Level 2: Rollout Flags (Platform Team-Controlled)

auth_service_rollout_percentage: 25%
auth_service_target_users: ["internal", "beta_customers"]
auth_service_exclude_users: ["enterprise_tier_1"]

Platform team controls gradual rollout. Can target specific cohorts.

Level 3: Feature Flags (Product-Controlled)

new_checkout_flow: "enabled_for_new_users"
advanced_reporting: "enterprise_only"

Product team controls user-facing features, regardless of underlying architecture.

The beauty: Product doesn’t care about infrastructure changes. They just see “checkout flow v2” enabled or not.

The Data Migration Strategy

Keisha, you mentioned data consistency challenges. Here’s what worked for us:

Phase 1: Dual Writes

Write to both old and new data stores
Read from old (source of truth)
Compare data periodically (catch inconsistencies)

Phase 2: Dual Reads

Still write to both
Read from new (source of truth)
Fall back to old if new fails
Monitor discrepancies

Phase 3: New Only

Write only to new
Read only from new
Old becomes archive

Each phase lasted 4-8 weeks depending on domain.

Specific Patterns That Maintained Velocity

Pattern 1: Bundle Architecture Work with User-Facing Features

Don’t say: “We’re spending Q2 migrating billing to a new service”

Say: “We’re launching subscription management v2, which includes migration to new architecture”

Result:

Product team gets their feature
Engineering gets architecture improvement
No “wasted” quarter on pure infrastructure

Example:

User-facing: Improved billing dashboard, better payment failure handling
Under the hood: Migrated to new billing service

Customers see value. Roadmap stays healthy. Architecture improves.

Pattern 2: Gradual Domain Extraction

Order of migration (easiest → hardest):

Authentication/Authorization (clear boundaries, well-understood domain)
Logging/Monitoring (already isolated concern)
Email/Notifications (external-facing, easy to abstract)
Reporting/Analytics (read-heavy, can run parallel)
Billing/Payments (critical but bounded domain)
Core Product Logic (last because most complex)

Start with wins. Build momentum. Learn patterns. Apply to harder domains.

Pattern 3: Shadow Mode Testing

Before rolling out new architecture:

Deploy new service in “shadow mode”
Send 100% of traffic to both old and new
Old handles requests, new just processes and logs
Compare results: are outputs identical?
Once proven equivalent, start routing real traffic

This caught so many bugs BEFORE customers saw them.

The Actual Velocity Impact (Our Numbers)

Baseline (pre-migration):

40 engineers, 18 features/quarter
Cycle time: 2.5 weeks

Migration Q1-Q2 (first 6 months):

40 engineers, 15 features/quarter (83% of baseline)
Cycle time: 2.8 weeks

Migration Q3-Q4 (next 6 months):

40 engineers, 16 features/quarter (89% of baseline)
Cycle time: 2.6 weeks

Post-migration:

40 engineers, 22 features/quarter (122% of baseline!)
Cycle time: 2.0 weeks

The velocity recovered and EXCEEDED baseline because new architecture was better.

The Coordination Overhead

Weekly sync between:

Platform team lead
Product team leads
Engineering manager
Product manager

Agenda:

What’s migrating this sprint?
Any conflicts with product roadmap?
Blockers or dependencies?
Rollout plan for completed migrations

Duration: 30 minutes

That’s it. Don’t over-coordinate. Trust the process.

What Didn’t Work

Things we tried that failed:

Migrating entire domains at once - Too risky, too slow. Migrate by capability within domain instead.
Perfect abstraction layers - We wasted time trying to create “clean” abstractions. Just accept temporary messiness.
Big planning upfront - We tried to plan all 18 months in advance. Didn’t work. Plan 1-2 quarters, adapt as you learn.
Separate “migration team” - Created silos. Hybrid model (platform + product teams) worked better.

Your Question About Product Commitments

“Can we still ship the Q2 features while migrating?”

Answer: Yes, if you prioritize.

What we told product:

“Here are the 5 critical features for Q2. We commit to those. Here are 3 stretch features. We’ll try but no guarantees during migration.”

What actually happened:

Delivered 4/5 critical (one slipped to Q3 by 2 weeks)
Delivered 1/3 stretch

Customer impact: Zero. They got what they needed.

The Real Answer

You can do this. Strangler fig + feature flags + incremental migration = maintained velocity.

Will it be 100% of pre-migration velocity? No.

Will it be 80-90%? Yes.

Is that acceptable to maintain business momentum while fixing architecture? Absolutely.

The alternative is waiting for a “perfect time” that never comes, then paying $2.3M like David did.

Take the 15% velocity hit. Complete the migration. Reap the benefits.

product_david · March 22, 2026, 5:26pm

From the product perspective, here’s what makes architectural migration compatible with roadmap commitments.

Bundle Architecture with User Value

Luis nailed it: Never do “pure infrastructure” work. Always bundle with user-facing improvements.

The Product Framing That Works

Instead of:
“Q2 is dedicated to migrating our authentication system to a new service architecture.”

Say:
“Q2 we’re launching Advanced Security Features (SSO, MFA, audit logging) which require modernizing our authentication infrastructure.”

Customer sees: New security capabilities
Engineering gets: New auth architecture
Board sees: Continued product momentum

Real Example from Our B2B Fintech

The migration we needed: Move from monolithic payment processing to event-driven architecture

The product story:

Q1: Launch real-time payment notifications (requires event bus)
Q2: Add payment analytics dashboard (requires event store)
Q3: Enable payment automation rules (requires event processing)
Q4: Provide payment audit trail (requires event sourcing)

What customers experienced: Four quarters of valuable payment features

What engineering accomplished: Complete migration to event-driven architecture

Nobody said “we’re not shipping features for a year while we refactor.”

The Roadmap Prioritization Framework

When architecture migration is happening, here’s how to prioritize:

Tier 1: Must Ship (Committed)

Revenue-critical features (enterprise deals depend on them)
Regulatory requirements (no choice)
Customer commitments (contractual obligations)

Allocation: 60% of engineering capacity

These ship no matter what. If migration conflicts, migration waits.

Tier 2: Should Ship (High Value)

Competitive parity features
Known customer pain points
Market expansion capabilities

Allocation: 20% of engineering capacity

These ship if possible. If migration conflicts, negotiate timeline.

Tier 3: Nice to Have (Opportunistic)

Experimental features
Technical improvements
Process enhancements

Allocation: 20% of engineering capacity (this is where migration lives)

These slip if needed. No customer commitments made.

Result: Customers get what they need. Engineering makes progress on architecture.

The Velocity Communication Strategy

What NOT to tell stakeholders:
“Velocity will drop 20% during migration.”

That creates panic, finger-pointing, and pressure to abandon the migration.

What TO tell stakeholders:
“We’re investing in platform capabilities that will improve velocity 30% long-term. Short-term, we’re prioritizing committed features and may deprioritize experimental work.”

Perception shift:

From: “Engineering is slow because of this migration thing”
To: “Engineering is smart about investing in long-term capabilities”

Managing Sales Expectations

Sales teams hate uncertainty. Here’s how to give them certainty during migration:

Clear Commitment Levels

Green: Fully Committed

Feature is in development now
Timeline: X date ±1 week
Safe to include in sales proposals

Yellow: Planned But Not Committed

Feature is on roadmap
Timeline: X quarter (no specific date)
Include in sales conversations but caveat

Red: Exploratory

Feature is being considered
No timeline
Don’t include in sales proposals

During migration:

More features move to Yellow
Fewer features are Green
That’s okay if you’re transparent

What sales needs: Honest timelines they can plan around, not optimistic promises that slip

The Customer Communication Decision

Should you tell customers about the migration?

Our decision: No.

Customers don’t care about your architecture. They care about:

Does the product work reliably?
Are you shipping features I need?
Is performance good?

What we communicated instead:

“We’re improving platform performance and scalability”
“We’re adding new security capabilities”
“We’re enhancing system reliability”

All true. All customer-focused. No mention of “migration.”

Exception: If customer experiences downtime or issues, be transparent about underlying cause.

The Feature Bundling ROI

Example: Checkout Flow Improvement

User story: Improve checkout conversion by reducing friction

Implementation options:

Option A: Quick Fix (Old Architecture)

Engineer effort: 2 weeks
Improvement: 2-5% conversion lift
Technical debt: Adds to legacy code
Future flexibility: Low

Option B: Rebuild on New Architecture

Engineer effort: 4 weeks
Improvement: 2-5% conversion lift (same as option A)
Technical debt: Reduces debt, uses new patterns
Future flexibility: High (can iterate faster going forward)

Product decision: “Option B takes 2x as long but sets us up for faster iteration on checkout experiments in the future. Let’s do it.”

Result:

Product gets their conversion improvement
Engineering makes migration progress
Velocity is 50% slower on THIS feature
But overall roadmap maintains because we bundled value

The Answer to “Will Migration Delay Delivery?”

Honest answer:

“Some features will take 10-20% longer because we’re using this opportunity to modernize underlying architecture. A few features might take 50% longer if they’re in areas being actively migrated. But committed features will ship. Exploratory features might slip. And the long-term payoff is 30%+ faster delivery once migration is complete.”

Then show the ROI:

Year 1: Slightly slower (85% velocity)
Year 2: Baseline velocity (100%)
Year 3+: Faster velocity (130%+)

“Would you rather maintain 100% velocity this year and 60% velocity next year? Or accept 85% velocity this year to enable 130% velocity ongoing?”

No executive chooses option 1.

What I Tell Engineering Leaders

Your job is to translate technical necessity into product opportunity.

Don’t fight for “migration time.” Bundle migration with product value. Show how architectural investment enables product capabilities.

The stakeholders don’t need to understand strangler fig patterns or feature flags.

They need to understand: “This investment makes us faster, more reliable, and more competitive.”

That’s a story any board will approve.

maya_builds · March 22, 2026, 5:26pm

The design system parallel is so relevant here. We did the exact same pattern—migrated component library while shipping features.

Migrating Design Systems Without Stopping Feature Delivery

Same challenge, different domain:

We had an inconsistent component library. Needed to rebuild it. But product needed features shipped.

The strangler fig pattern works for design too.

Our Design System Migration Pattern

Phase 1: Build New in Parallel

Created new design system (Figma + React components)
Old components still in use
No features blocked

Phase 2: Use New for All New Features

Rule: “New features must use new component library”
Legacy features can keep old components (for now)
Gradually new system spreads

Phase 3: Migrate High-Traffic Pages

Identify top 10 most-used pages
Migrate them to new components incrementally
Both old and new coexist

Phase 4: Deprecate Old

Set sunset date for old components
Migrate remaining pages
Remove old system

Timeline: 14 months
Feature delivery impact: 10-15% slower initially, back to baseline by month 6

The Component-Level Feature Flags

Just like code feature flags, we used design variants:

const Button = ({ variant }) => {
  if (useNewDesignSystem) {
    return <NewButton variant={variant} />
  }
  return <OldButton variant={variant} />
}

Allowed us to:

A/B test old vs new design
Roll out gradually per page
Roll back if users complained
Measure impact (conversion, engagement)

Bundle Design System Work with Product Features

Example: Dashboard Redesign

Product wanted: Improved dashboard with better data visualization

Design opportunity: Use this as chance to implement new component system

Outcome:

Product got their redesigned dashboard
Design got to showcase new component library
Engineering built reusable components for new system

Timeline: 6 weeks (would have been 4 weeks with old components, but investment paid off)

The Velocity Impact (Real Numbers)

Pre-migration:

4 designers, 8 frontend engineers
12 features/quarter with design work

During migration (months 1-6):

Same headcount
10 features/quarter (83% of baseline)
Reason: Designers building components + implementing features

During migration (months 7-12):

Same headcount
11 features/quarter (92% of baseline)
Component library growing, less custom work

Post-migration (month 13+):

Same headcount
15 features/quarter (125% of baseline!)
Reason: Designers don’t build components anymore, just compose

The investment paid back in 14 months.

The Coordination Between Design and Engineering Migration

Critical insight: Design system migration must align with backend architecture migration.

If engineering migrates to new services but design still uses tightly-coupled components, you’re not gaining much.

What worked:

Weekly sync between design system team and platform engineering team
Shared roadmap: “When billing service migrates, billing UI components migrate too”
Bundled releases: “Billing v2 includes new architecture AND new design”

What didn’t work:

Trying to migrate design system independently (created misalignment)
Waiting for engineering to finish before starting design work (wasted time)

The right approach: Parallel migration, coordinated releases

The Communication Strategy for Design Changes

Keisha asked about managing product expectations. Here’s the design version:

What NOT to say:
“We’re rebuilding the component library so designs will take longer.”

What TO say:
“We’re investing in a design system that will make future features 30% faster to design and build. This quarter, some features take slightly longer as we build reusable components.”

Stakeholder perception:

From: “Design is slow because they’re rebuilding something that already works”
To: “Design is investing in efficiency that pays long-term dividends”

The User Impact Question

Did users notice the component migration?

Mostly no. We:

Maintained visual consistency (new components looked similar to old)
Didn’t change flows (same interactions, better implementation)
Rolled out gradually (no sudden dramatic changes)

Where they DID notice:

Performance improved (new components were lighter)
Accessibility better (new components WCAG compliant)
Animations smoother (new components better optimized)

User feedback: Positive. They noticed the product felt more polished, didn’t know why.

The Parallel to Your Technical Migration

Keisha, your architectural migration will be similar:

Users won’t notice:

That you moved to microservices
That you’re using new data stores
That infrastructure is different

Users WILL notice:

Performance improvements
New features unlocked by better architecture
Fewer bugs and incidents
Smoother experience

That’s the right outcome. Architecture is implementation detail. User value is what matters.

The Hybrid Team Model for Design

We also did hybrid (like engineering Option C):

Design Systems Team (2 designers, 2 engineers):

Built core component library
Created documentation and guidelines
Supported product teams with integration

Product Teams (remaining designers/engineers):

Used new components for features
Provided feedback to design systems team
Migrated their domains incrementally

Why it worked:

Centralized expertise (design systems team knew patterns deeply)
Distributed implementation (product teams maintained domain context)
No silos (everyone collaborated, clear boundaries)

What I’d Tell You

Keisha, you asked what actually worked in practice.

What worked:

Strangler fig pattern (build new alongside old)
Feature flags (control rollout)
Bundle with user value (never “pure infrastructure”)
Hybrid team model (platform + product teams)
Incremental migration (domain by domain)

What didn’t:

Big planning upfront (just start, learn as you go)
Trying to maintain 100% velocity (accept 15% drop)
Waiting for “perfect time” (there isn’t one)

Velocity impact:

Expect 15-20% drop initially
Back to baseline by month 6-9
Exceeds baseline by month 12-18

80 engineers taking 15% velocity hit = losing 12 engineers worth of capacity temporarily

But gaining 30%+ velocity long-term = gaining 24 engineers worth of capacity permanently.

That ROI is obvious.

You can do this. Ship features AND migrate architecture. It’s been done hundreds of times.

Just commit to the incremental approach and don’t let perfect be enemy of good.