Our team recently concluded an 18-month migration from a legacy, self-hosted project management suite (Jira Server) to a modern cloud-native platform (Linear). The primary technical constraint was the need to maintain access to nearly a decade of ticket history, comments, and attachments for audit and reference purposes, while simultaneously wanting the agility and developer experience of the new tool for all future work.
A hard cutover was deemed too risky due to the volume of in-flight projects and the institutional knowledge embedded in the old system. Conversely, a full data migration was estimated to require a complex, error-prone ETL process with significant data transformation costs and a high probability of data loss in complex field mappings. Our solution was a structured hybrid approach, which I've termed a "read-only legacy archive with a forward-looking gate."
The operational model was as follows:
* **New Projects & Active Work:** All new initiatives, features, and bugs created after **Cutover Date (T0)** were mandated to use the new tool (Linear). This was enforced by team policy and integrated into our new project kickoff workflows.
* **Historical Archive:** The legacy Jira instance was not decommissioned. It was scaled down to minimal necessary resources (cost analysis below) and placed into a strictly read-only state for all users. Administrative functions were disabled.
* **Cross-Linking Protocol:** For any active work in the new tool that required context from the old, we established a naming convention and linking standard. The legacy ticket ID was prefixed with "LEGACY-" and included in the new ticket's description.
**Technical & Cost Implementation for the Legacy Archive:**
The significant cost saving came from aggressively right-sizing the legacy infrastructure, which originally ran on three `m5.2xlarge` EC2 instances for high availability.
```yaml
# Simplified Terraform for the archived Jira state
resource "aws_instance" "jira_archive" {
ami = data.aws_ami.ubuntu.id
instance_type = "t3.medium" # Downscaled for minimal web/DB load
subnet_id = aws_subnet.private.id
root_block_device {
volume_size = 100 # Reduced from 500GB GP2 to 100GB GP3
volume_type = "gp3"
}
# Instance Schedule: Stopped outside business hours (Mon-Fri, 8AM-6PM)
lifecycle {
ignore_changes = [instance_state]
}
# (Schedule managed via AWS Instance Scheduler)
}
```
**Cost Breakdown (AWS):**
* **Pre-Archive (Production):** ~$650/month (Compute + Storage + RDS)
* **Post-Archive (Read-Only):** ~$95/month
* Compute (t3.medium, scheduled): ~$25
* Storage (GP3): ~$8
* RDS Single-AZ db.t3.small (with reduced backup retention): ~$62
**Key Challenges & Mitigations:**
* **Team Buy-In:** Developers resisted checking two places. We mitigated this by creating a simple internal web proxy that redirected any attempt to access a legacy ticket URL (`/browse/OLD-123`) to the archived instance, and any new ticket URL (`/issue/NEW-456`) to the new tool. This created a seamless enough experience.
* **Search Discontinuity:** Global search was broken. Solution: We provided a dedicated, bookmarked "Advanced Search" page in the archived instance and trained teams on when to use it.
* **Sunk Cost Mindset:** Stakeholders questioned why we were paying for anything at all. Presenting the cost breakdown ($95 vs. the estimated $15k+ for a full, safe migration and the risk of data loss) solidified buy-in.
The hybrid approach proved successful. It allowed us to capture the benefits of the modern tool immediately for new work, while treating the historical data as a cold-storage, referenceable archive. The operational overhead is minimal, and we have a clear, low-cost runway for the next 5-7 years until the historical data can be considered for final deletion.
I am interested in hearing from others who have implemented similar patterns, particularly regarding how you handled authentication bridging between systems or automated the archival of the old instance after a certain period of inactivity.
-cc
every dollar counts