---
title: Repurchase
description: Repurchase provides a high-level SaaS transition model across vendor solutions and is managed outside wave-based migration factory delivery.
sidebar:
  label: Overview
  order: 0
source_url: "https://framework.stackit.cloud/migration/migrate/repurchase/overview/"
source_file: "docs/migration/migrate/repurchase/overview.mdx"
---

## Understanding the Repurchase module

Repurchase addresses transitions where a workload is replaced by a SaaS solution.
This path follows different migration mechanics than technical relocation into STACKIT landing zones.

Because SaaS implementations vary by product, this module documents only shared cross-solution patterns.

## Why Repurchase is outside the factory

- **Vendor-specific delivery**: Data migration, identity integration, and process mapping differ per SaaS product.
- **Business-process dependency**: Operating model and process redesign are often as important as technical cutover.
- **Different risk profile**: Contract, compliance, and adoption risks dominate over infrastructure migration risks.

## Common Repurchase transition flow

<Steps>

1. Confirm business capability fit and target operating model for the selected SaaS solution.
2. Define data scope, identity model, integration contracts, and compliance boundaries.
3. Plan coexistence and cutover strategy between legacy and SaaS systems.
4. Migrate data and configure integrations in controlled increments.
5. Validate process outcomes, security controls, and user readiness.
6. Complete cutover, decommission legacy dependencies, and stabilize operations.

</Steps>

## Shared outputs

<CardGrid>
  <Card title="Transition blueprint">
    Scope, interfaces, migration approach, rollback criteria, and ownership model for the SaaS
    transition.
  </Card>
  <Card title="Adoption and enablement plan">
    Structured onboarding and communication plan for affected users and support teams.
  </Card>
  <Card title="Compliance and governance evidence">
    Documented controls for identity, data handling, auditability, and contractual obligations.
  </Card>
</CardGrid>

## Boundary to migrate, optimize, and refactor

- Repurchase is intentionally separated from wave-based [Migrate](/migration/migrate/migrate/overview/).
- Post-cutover tuning may still use selected [Optimize](/migration/migrate/optimize/overview/) practices.
- Refactor-heavy transformation remains in [Refactor](/migration/migrate/refactor/overview/).