7Rs Migration Strategy

Migration Candidateを識別した後は、

このApplicationを
どのような方法で扱うか

を考えます。

AWSへのMigrationでは、代表的な移行戦略として7Rsがあります。

Rehost

Replatform

Refactor / Re-architect

Repurchase

Relocate

Retain

Retire

重要なのは、

AWSへ移す
=
すべてRehost

ではないことです。

Applicationごとに、

現在のApplicationを残したい？

どの程度変更できる？

新しい製品へ置き換える？

現在は移行しない？

そもそも残す必要がある？

という条件が異なります。

ゴール

このページでは、

Applicationをどう扱いたい？
↓
ほぼ変更せず移す
→ Rehost

一部をCloud向けに最適化して移す
→ Replatform

アーキテクチャ自体を再設計する
→ Refactor / Re-architect

別製品 / SaaSへ置き換える
→ Repurchase

既存Platformを大きく変えず移す
→ Relocate

今はSource Environmentに残す
→ Retain

不要なので廃止する
→ Retire

という違いを判断できることがゴールです。

1. 7Rsは「AWSへ移す方法」だけではない

7Rsの中には、

AWSへ移す戦略

だけでなく、

今は移さない

Application自体を廃止する

という判断も含まれます。

例えば、

Rehost
Replatform
Refactor
Repurchase
Relocate

はApplicationの移行や置き換えに関係します。

一方、

Retain
Retire

では、

今はSource Environmentへ残す

または

Application自体を終了する

という判断になります。

したがって最初から、

どのAWS Serviceへ移す？

だけを考えないことが重要です。

2. Rehost — Applicationをほぼ変更せず移す

Rehostは、

Lift and Shift

とも呼ばれます。

基本的な考え方は、

現在のApplication
↓
Applicationへ大きな変更を加えない
↓
AWSへ移行

です。

例えば、

On-premises VM
↓
Amazon EC2

のように、現在のApplication構成を大きく変更せず移します。

3. Rehostの決定打は「Migration時の変更を最小化したい」

例えば、

Data Center退去期限
→ 6か月後

Application
→ 現在正常稼働

大規模なコード変更
→ Migration期限内には困難

という状況なら、

まずCloudへ移してから後で最適化する方針が考えられます。

この場合、

変更量を抑える

Migration速度を優先

アーキテクチャのモダナイゼーションは後段

という条件から、

Rehost

が候補になります。

Rehostを選んだからといって、

将来も永遠に同じアーキテクチャ

という意味ではありません。

Migration後にモダナイゼーションすることもできます。

4. Replatform — 移行と同時に一部を最適化する

Replatformは、

Lift, Tinker and Shift

または、

Lift and Reshape

とも呼ばれます。

考え方は、

現在のApplication
↓
一部をCloud向けに最適化
↓
ただし全面的なアーキテクチャ再設計まではしない
↓
AWSへ移行

です。

5. ReplatformはRehostとRefactorの中間にある

例えば現在、

Application
↓
EC2相当のServer

Database
↓
自己管理

という構成があるとします。

Application全体を書き直すのではなく、

Application
→ 大きく維持

Database
→ マネージドデータベースへ変更

のように、一部のPlatformをCloud向けに最適化する場合はReplatformを検討できます。

つまり、

ほぼそのまま
→ Rehost

一部最適化
→ Replatform

アーキテクチャを大きく再設計
→ Refactor / Re-architect

と区別します。

6. マネージドサービスを使うだけで必ずReplatformとは限らない

移行戦略は、

AWS Service名

だけで決めません。

同じAmazon RDSなどを利用する場合でも、

Application構造

Database Engine

コード変更

Target Architecture

によって必要な変更量は異なります。

重要なのは、

どのServiceを使うか

ではなく、

現在のApplicationからTargetへどの程度変更するか

です。

したがって、

マネージドサービスを使う
=
必ずReplatform

ではありません。

7. Refactor / Re-architect — アーキテクチャ自体を再設計する

Refactor / Re-architectは、

現在のアーキテクチャ
↓
アーキテクチャを変更
↓
クラウドネイティブな機能を活用

する戦略です。

例えば、

Monolithic Application

が、

スケーリングしにくい

Releaseに時間がかかる

変更の影響範囲が大きい

という業務・技術上の問題を抱えている場合、

単にServerをAWSへ移すだけでは根本問題が残ります。

そこで、

アーキテクチャ自体を再設計

することを検討します。

8. Refactorは「移行ついでの小変更」ではない

例えば、

OS Versionを更新する

Databaseをマネージドサービスへ移す

Instance Sizeを変える

程度だけであれば、必ずしもRefactorではありません。

Refactor / Re-architectでは、

Application Componentの分割

Architecture Patternの変更

Cloud-native設計への変更

など、

Applicationのアーキテクチャそのものへ大きな変更

を加えます。

そのため一般に、

変更量

複雑さ

試験範囲

も大きくなります。

9. 大規模MigrationではRefactorを無条件に選ばない

Cloud-native化にはメリットがありますが、

Cloud-native
=
Migration時に必ずRefactor

ではありません。

大規模Migrationでは、

Application数が多い

Migration期限が短い

変更Riskを抑えたい

場合があります。

そのため、

まずRehost / ReplatformなどでMigration
↓
Migration後にModernize

する方が適切な場合もあります。

重要なのは、

モダナイゼーションの効果とMigration時の変更量を分けて考えること

です。

10. Repurchase — Applicationを別製品へ置き換える

Repurchaseは、

Drop and Shop

とも呼ばれます。

現在のApplicationをそのままAWSへ移すのではなく、

現在のApplication
↓
別のProduct / Serviceへ置き換え

ます。

代表的なのは、

On-premises Package
↓
Vendor SaaS

への置き換えです。

11. Repurchaseでも移行作業がなくなるわけではない

Repurchaseの場合、

旧ApplicationのServerを
そのままAWSへ移す

わけではありません。

しかし、

既存Data

User

Authentication

Integration

などを新しいProductへ移行・接続する必要がある場合があります。

つまり、

Applicationを置き換える
=
移行作業がなくなる

ではありません。

変わるのは、

既存Applicationを移すのではなく、新しいProductへ業務を移行する

という点です。

12. Relocate — 既存Platformを大きく変えず移す

Relocateでは、

Applicationのアーキテクチャ

を大きく変更せず、

既存Platform / Infrastructure単位

で移します。

AWSの現在の定義では、大量のServerを含むPlatformをCloud版Platformへ移したり、既存AWS Resourceを別VPC・Region・Accountへ移すケースなどもRelocateに含まれます。

基本的な考え方は、

既存の運用モデルやアーキテクチャを
できるだけ維持
↓
配置場所を変更

です。

13. RehostとRelocateを区別する

RehostもRelocateも、

大きなApplication Rewriteを避ける

点では似ています。

違いは判断単位です。

Rehost

Application / Serverを
AWS Infrastructureへ移す

Relocate

既存PlatformやInfrastructure群を
アーキテクチャを大きく変えず移す

つまり、

Server / Application中心のLift and Shift
→ Rehost

Platform / Environment中心の移動
→ Relocate

と考えると区別しやすくなります。

14. Retain — 今は移行しない

Retainは、

Source Environmentへ残す

戦略です。

例えば、

Data Residency制約

特殊Hardware Dependency

Migration Riskが高い

別Applicationを先に移行する必要がある

最近大きな設備投資をした

近い将来SaaS版へ置き換える予定

などにより、

現在はAWSへ移さない

という判断ができます。

15. Retainは「永遠にOn-premises」の意味ではない

RetainしたApplicationでも、

現在は移さない

だけで、

将来も絶対に移さない

とは限りません。

例えば、

Dependency解消

Hardware Refresh

Compliance要件変更

SaaS提供開始

などにより、後から戦略を再評価できます。

したがって、

Retain
=
現在のMigration Scopeでは残す

と考えます。

16. Retire — Applicationを廃止する

Retireは、

ApplicationをMigrationしない

点ではRetainと似ています。

しかし理由が違います。

Retireでは、

Application自体を
Decommission / Archive

します。

例えば、

利用者がいない

業務価値がない

別Systemへ機能統合済み

維持Costだけ発生

古いComponentのSecurity Riskがある

ようなApplicationです。

17. RetainとRetireを区別する

Retain

Applicationは必要
↓
現在は移さない
↓
Source Environmentで継続

Retire

Applicationを残す必要がない
↓
停止 / 廃止

したがって、

AWSへ移さない

という結果だけで両者を同じにしないことが重要です。

決定打は、

Applicationを今後も使う必要があるか

です。

18. 7Rsを変更量で整理する

Migration Strategyは、Applicationへ加える変更の大きさでも整理できます。

変更しない / 最小
│
├─ Relocate
│
├─ Rehost
│
├─ Replatform
│
└─ Refactor / Re-architect
               │
               ↓
           変更が大きい

ただし、

Repurchase

は既存Applicationを新Productへ置き換えるため、この一本の変更量だけでは表せません。

また、

Retain / Retire

はAWSへApplicationを移す戦略ではありません。

この整理は、

似ている戦略を区別するための目安

として使います。

19. 7Rsはビジネス要因と技術的制約から選ぶ

戦略を選ぶときは、

どれが最もCloud-nativeか

だけを基準にしません。

例えば、

Migration期限

Application変更許容度

業務価値

モダナイゼーションの必要性

Vendor Productの有無

Compliance

Physical Dependency

などが関係します。

例1

Data Center退去
→ 6か月

コード変更
→ 最小化したい

ならRehostが候補になります。

例2

現在のPackage
→ SaaS版へ置換可能

Infrastructure運用
→ 終了したい

ならRepurchaseが候補になります。

例3

Monolith
→ 事業成長を阻害

アーキテクチャ変更
→ 許容

ならRefactor / Re-architectが候補になります。

20. Strategy名だけではTarget Architectureは確定しない

例えば、

Replatform

と判断しても、

具体的にどのAWS Serviceへ移すか

まですべて自動的に決まるわけではありません。

同様に、

Refactor

と判断しても、

Serverless

Container

Event-driven

のどれを採用するかは別のアーキテクチャ判断です。

7Rsは、

Migrationの方向性

を表します。

具体的なTarget Architectureの詳細は、Application Requirementを基に後続で決定します。

21. 7Rs選択は後続Planningの入力になる

7Rsを分類すると、

どのApplicationを
どの方向で扱うか

が明確になります。

例えば、

Application A
→ Rehost

Application B
→ Retire

Application C
→ Repurchase

Application D
→ Replatform

という形です。

この情報は後続で、

Cost / Business Case

移行の複雑さ

Migration Wave

Migration Sequence

などを評価する際の入力になります。

このページでは、それらの詳細な比較までは行いません。

22. 7Rsの全体フロー

Applicationを今後も必要とする？
│
├─ No
│   → Retire
│
└─ Yes
    ↓
現在AWSへ移行する？
│
├─ No
│   → Retain
│
└─ Yes
    ↓
別Product / SaaSへ置き換える？
│
├─ Yes
│   → Repurchase
│
└─ No
    ↓
既存Platformを大きく変えず移す？
│
├─ Yes
│   → Relocate
│
└─ No
    ↓
Applicationをほぼ変更せず移す？
│
├─ Yes
│   → Rehost
│
└─ No
    ↓
一部最適化で十分？
│
├─ Yes
│   → Replatform
│
└─ No
    ↓
アーキテクチャ自体を再設計
→ Refactor / Re-architect

これは絶対的な実装手順ではなく、

7つのStrategyの違いを整理するための判断フロー

です。

混同ポイント

SAP-C02での判断

7Rsを問われた場合は、

Applicationは必要？
↓
今Migrationする？
↓
Product自体を置き換える？
↓
Platformをそのまま移す？
↓
Application変更を最小化する？
↓
一部最適化する？
↓
アーキテクチャを再設計する？

と考えます。

決定打は、

現在のApplicationを
どの程度残し

どの程度変更し

そもそも移行するのか

です。

まとめ

7Rsは、

Rehost
→ Applicationをほぼ変更せず移行

Replatform
→ 一部をCloud向けに最適化して移行

Refactor / Re-architect
→ アーキテクチャ自体を再設計

Repurchase
→ 別Product / SaaSへ置き換え

Relocate
→ 既存Platformを大きく変えず移動

Retain
→ 現在はSource Environmentへ残す

Retire
→ Applicationを廃止

と整理できます。

重要なのは、

AWS Service名

だけでStrategyを決めることではありません。

ビジネス要因
+
変更許容度
+
現在のApplicationの業務価値
+
技術的制約

を使って、Applicationに適した方向性を判断します。