Height to Linear: Engineering-Focused PM Switch

1. Introduction: Navigating the Shift from Height to Linear

In the competitive landscape of project management, choosing the right tool is rarely a static decision. You may have started with Height for its spreadsheet-like flexibility and unique approach to task management, but as your UK SME scales, you might find yourself hitting the limits of its architecture or seeking the specific power-user workflows that Linear is famous for.

Switching platforms is a significant operational undertaking. It is natural to feel apprehension regarding business downtime, the potential for data loss, and the disruption to your team’s established rhythms. This guide is designed to replace that anxiety with a structured, risk-managed roadmap.

Disclosure: TrustSwitch may receive affiliate commissions from software providers mentioned in this guide. Our recommendations remain independent and are based solely on technical evaluation and migration feasibility.

The transition from Height to Linear is not merely a change of interface; it is a migration of your business’s operational intelligence. By following this data-driven approach, you can mitigate the "medium" risk profile associated with this move and ensure your team maintains momentum.

2. Why Companies Switch: Triggers and Limitations

Understanding why you are moving is as important as the move itself. Most SMEs we consult decide to migrate from Height to Linear for three primary reasons:

• Workflow Velocity: Linear is purpose-built for high-velocity software development teams. If your team requires highly opinionated, keyboard-centric workflows and advanced issue-tracking hierarchies that Height’s "spreadsheets-first" approach doesn't prioritise, the switch is often justified.
• Engineering Integration Depth: Linear offers deep integrations with GitHub, GitLab, and Sentry that are often more tightly coupled than generic project management tools.
• Scalability of Governance: As teams grow beyond 50 people, Linear’s "Cycles" and "Roadmaps" features provide a more rigid, scalable structure for planning compared to Height’s more fluid, list-based views.

The Trade-off: While you gain speed and structure, you lose the extreme customisation of Height’s "everything is a field" philosophy. You are trading infinite flexibility for deliberate, high-performance efficiency.

3. Migration Risk Assessment

Migration is a technical project, not just an administrative one. We categorise this transition as "medium risk" because both platforms offer robust APIs, but the data models differ significantly.

Downtime Reality Check: True downtime is rare if you adopt a phased cutover. The fear of "revenue loss" usually stems from a lack of internal communication rather than technical outages. By keeping your current instance in "Read-Only" mode during the transition, you ensure no data is lost while the new system is verified.

4. Pre-Migration Checklist

Before you move a single task, you must prepare your data environment. Skipping this step is the primary cause of failed migrations.

• Audit Current Usage: Identify which Height fields are actually used versus legacy clutter.
• Golden Copy Backup: Export all data from Height into a clean JSON/CSV format and store it in a secure, encrypted location (e.g., AWS S3 or a local encrypted server).
• Account Prep: Ensure all team members have Linear accounts pre-provisioned with correct permissions.
• Field Mapping Map: Create a spreadsheet mapping Height "Attributes" to Linear "Properties." Ensure you account for differing status workflows.
• Integrations Audit: List all third-party apps connected to Height (Zapier, Slack, GitHub) and prepare their Linear counterparts.

5. Step-by-Step Migration Process

Phase 1: Pilot

Select one non-critical team (e.g., a small side project or the marketing team) to migrate first. This "smoke test" will reveal if your field mapping logic holds up.

Phase 2: Parallel Running

For one sprint cycle, run both systems. The pilot team uses Linear for daily work but updates Height once daily. This builds team confidence and verifies data parity without jeopardising the business.

Phase 3: Full Migration

Execute the migration during a weekend. Use the official Linear importer or a middleware tool like Zapier/Make to sync active issues. Once the sync is verified, switch Height to "Read-Only."

Phase 4: Post-Migration

Archive the Height instance only after 30 days of successful operation in Linear. Conduct a "Retrospective" with your team to address any immediate workflow friction.

6. Common Pitfalls & How to Avoid Them

• The "Everything Must Move" Trap: Do not migrate closed tasks from three years ago. Only migrate active tasks and the current sprint. Archive old data in a static file; moving it into the new live environment only creates "noise."
• Ignoring API Rate Limits: When syncing thousands of tasks, you may hit API rate limits. Ensure your migration script includes "sleep" functions or use a professional migration service if the volume exceeds 5,000 tasks.
• Mapping Mismatch: Height’s "Custom Statuses" are highly flexible. If you try to map these to Linear’s more structured "Workflow States," you might lose data. Map to the closest equivalent state and use "Labels" to preserve the nuance of the original status.

7. UK GDPR Considerations

As a UK-based business, you must ensure your data stays compliant during the transition.

• Data Residency: Both Height and Linear are global SaaS providers. Check their latest Data Processing Agreement (DPA) to ensure they offer Standard Contractual Clauses (SCCs) or are compliant with the UK-US Data Bridge.
• Data Minimisation: Use this migration as an opportunity to purge old PII (Personally Identifiable Information) from your task comments and attachments.
• Right to Erasure: Ensure your new Linear setup allows for the easy export or deletion of user data, fulfilling your obligations under the UK GDPR.

8. Cost Breakdown

Migration is not free. Beyond the subscription fees, you must account for:

• Direct Costs: Subscription fees for both tools (overlap period).
• Hidden Costs: Time spent by your engineering lead on mapping (calculate their hourly rate x hours spent).
• Tooling Costs: If you purchase a third-party migration tool or pay for developer hours to write custom scripts.
• Cancellation Costs: Check your Height contract. Some enterprise tiers have notice periods that require payment even after you stop using the service.

9. When NOT to Switch

Sometimes, the best move is to stay put. Avoid switching if:

• Your team is currently in the middle of a high-stakes, time-sensitive product launch.
• Your project management needs are primarily administrative (e.g., HR or Finance tasks) rather than software-development focused.
• You lack the technical resource to manage the API mapping process.

10. FAQ

Q: Will I lose my file attachments? A: Most automated importers handle links to attachments, but direct file transfers can be tricky. Ensure your migration script includes the download/re-upload logic for critical assets.

Q: How long does the migration take? A: For an average SME (20-50 users), expect 2-4 weeks of planning and testing, with a "go-live" weekend.

Q: Can I keep Height running as an archive? A: Yes, but ensure you downgrade your subscription to the lowest possible tier to save costs while maintaining read access.

11. Next Steps

1. Designate a Migration Lead: This should be someone with both project management and basic technical oversight.
2. Run a Data Audit: Export your Height data this week to see exactly what you are working with.
3. Book a Demo: Reach out to Linear’s sales team specifically regarding your "migration from Height" to see if they can provide internal migration templates or support.

Remember: The goal of this transition is to improve your team’s output, not to create a permanent administrative burden. Plan slow, execute fast.