Heroku移行は必要？判断基準と移行先の選び方をわかりやすく解説

2026年2月6日、Herokuは公式ブログで開発体制の転換を発表しました。sustaining engineering model、つまり維持運用に専念する体制への移行です。新機能を追加することよりも、安定性、セキュリティ、信頼性、サポートを重視するという内容でした。

この発表を「サービス終了の予告」と受け取ると、判断を誤ります。同じ発表のなかで、変わらないことも明記されています。クレジットカードで支払っている顧客は、新規・既存を問わず料金や課金、サービス内容に変更はありません。アプリケーション、パイプライン、Team、アドオンといった中核機能も影響を受けず、本番の業務システムをこれまでどおり載せ続けられるとされています。

変わるのは、新規顧客向けのEnterprise Account契約が提供されなくなる点です。すでにEnterprise契約を結んでいる場合は、契約とサポートが引き続き履行され、更新もできます。

つまり、期限が切られたわけではありません。移行を判断する軸は「いつまでに逃げるか」ではなく、今後の計画がHerokuの上で成立するかどうかです。次の項で、その切り分け方を示します。

Herokuの仕組みや料金の全体像はHerokuとはで解説しています。

移行の要否は、システムの状態と今後の計画で決まります。まず、検討したほうがいいケースからです。

今後数年で機能追加を織り込みたい場合は、検討の対象になります。プラットフォーム側に今後どのような新機能が加わるかを前提にした計画は、これまでより立てにくくなったためです。プラットフォーム側の新しい機能を取り込みながら育てていくサービスでは、この方針転換を織り込んでおく必要があります。

新規のお客様としてEnterprise Account契約を結ぶ予定だった場合も同様です。新規向けの提供が終了しているため、その前提の構成は組めません。

月額が膨らんでいるケースも対象です。Dynoの数や必要なリソースが増えるほど、IaaSなど他の選択肢との料金差が大きくなることがあります。規模が読めているなら、比較する価値があります。

データを国内に置く要件が新たに発生した場合も、確認が必要です。Herokuの標準環境であるCommon Runtimeに東京リージョンはなく、東京を使うにはPrivate Spaceが必要になります。使えないわけではありませんが、費用の桁が変わります。

一方で、急がなくていいケースのほうが多いのが実情です。現行の構成で安定して動いていて、大きな機能追加の予定もなく、月額も数十ドルの範囲に収まっている。既存のEnterprise契約がある。こうした状態なら、慌てて動く理由は見当たりません。移行には費用も工数もかかります。動かないという判断も、正当な選択肢です。

移行先は大きく3つの型に分かれます。1つ目はHerokuと同じPaaSで、Render、Railway、Fly.ioなどが該当します。操作感が近く、移行の考え方も似ています。2つ目はコンテナを動かすマネージドサービスで、AWS App RunnerやGoogle Cloud Runがここに入ります。3つ目はAWSのEC2に代表されるIaaSで、自由度は高い代わりに構築と運用を自分たちで担います。

日本向けのサービスでは、最初のフィルタが東京リージョンの有無になります。主要な候補の状況は次のとおりです（2026年9月時点、各社の公式ドキュメントより）。

RenderとRailwayは、Herokuからの移行先として名前が挙がることの多いサービスです。ただし現時点で東京リージョンがなく、最も近い拠点はシンガポールになります。日本国内のユーザーが使うシステムでは、通信の遅延とデータの所在の両面で確認が必要です。

逆に、利用者が国内に限られない、あるいは通信の遅延がユーザー体験に大きく影響しないシステムであれば、東京リージョンの有無だけで候補を絞る必要はありません。自社のシステムがどちらなのかを先に決めると、選択肢が整理できます。

「Herokuは簡単だったのに、移行の見積もりは高い」。このギャップは、Heroku固有の仕組みにどれだけ寄りかかっていたかで決まります。作り直しになりやすいのは次の5か所です。

1. アドオンへの依存
Heroku PostgresやKey-Value Storeといったデータストア、監視、メール配信などを、コマンド1つで追加できていました。移行先に同等のものがなければ、個別に契約し直し、設定し直すことになります。使っている数が多いほど工数が積み上がります。

2. データベースの移し替え
Herokuのバックアップ機能はPostgreSQL標準のpg_dumpを使うため、書き出して他のPostgreSQLへ移すこと自体は難しくありません。ただし公式は、この方法が想定するのは20GB程度までのデータベースだとしています。それを超える場合は別の手順が必要になり、工数もダウンタイムの設計も変わります。

3. ビルドの仕組み
Herokuでは、送ったコードから言語を判別して実行環境を組み立てるBuildpackが裏側で動いていました。移行先によっては、そこで自動的に行われていた内容をDockerfileなどで明示的に書き起こす必要が出てきます。

4. 環境変数と認証情報
長く動いているシステムほど、設定値のどれが生きていてどれが不要なのかが分かりにくくなります。棚卸しそのものが作業になります。

5. 周辺の運用機能
定期実行、ログの転送、検証環境の自動生成。あって当たり前だったものほど、移行の計画から抜け落ちます。

弊社もHerokuで3年近く本番運用してきました。プルリクエストごとに検証環境が立ち上がるReview Appsや、ログ監視をSlack通知に集約する構成には、かなり助けられています。裏を返せば、こうした仕組みに寄りかかっているほど移行は重くなります。運用面で何がHeroku固有だったかはHeroku本番運用3年の学びにまとめています。

移行費用の相場を示すことはできません。同じ「Herokuからの移行」でも、アドオンを3つ使っているシステムと10個使っているシステムでは、作業量が何倍も変わるためです。相場ではなく、見積書の内訳を読む視点を持つほうが確実です。

確認したいのは4項目です。

1. アプリケーション本体の移植
2. データベースの移行と、移行後のデータ検証
3. アドオンで担っていた機能の作り直し
4. 移行後の並行稼働とテスト

見落とされやすいのは3番目と4番目です。1番目と2番目だけを積んだ見積もりでは、実際に必要な作業を捉えきれていない可能性があります。特に4番目は、切り替え時にどこまでサービス停止を許容できるかで工数が変わるため、要件として先に決めておく必要があります。

もう1つ、移行後の月額も同時に試算してください。移行費用だけを見て決めると、ランニングコストがHeroku時代より上がっていた、という結果になりかねません。移行先の料金体系はサービスごとに考え方が違うので、自社の構成に当てはめた金額で比べることになります。

見積書の内訳に不明な点があれば、提案元に確認するのが早道です。弊社でも、移行するかどうかの判断段階からのご相談を承っています。

実際に移行すると決めた場合、進め方は次の順になります。

1. 棚卸し
いま何が動いているのかを洗い出します。Dynoの構成、使っているアドオン、環境変数、定期実行の処理。ここの精度が、この後のすべてを決めます。移行の期間も費用も、実際にはこの棚卸しの結果で決まります。

2. 移行先の選定
東京リージョンが要るかどうか、アドオンで担っていた機能の代わりが用意できるかどうかで絞り込みます。候補が2つか3つに減れば、あとは料金と運用体制の比較です。

3. 検証環境で通す
本番と同じ構成を移行先に一度作り、動くところまで確認します。ここで想定外の問題が見つかることは珍しくないため、この工程は省けません。

4. 本番の切り替え
データ移行のタイミングとドメインの切り替えを設計します。サービスを止められない場合は、一時的に両方を動かす構成を組むこともあります。

1と3を丁寧に進めるほど、本番切り替えのリスクは下がります。逆に棚卸しを飛ばして進めると、切り替え当日に問題が出やすくなります。

Herokuはいつまで使えますか

終了時期は発表されていません。2026年2月の発表では、本番運用に耐えるプラットフォームとして提供を続けると明記されています。期限を前提にした移行計画を立てる必要は、現時点ではありません。

移行しないとセキュリティ上の問題がありますか

今回の方針転換は、セキュリティや安定性への対応をやめるという内容ではありません。むしろ、新機能の追加よりもそちらを重視する体制へ移るという発表です。

既存のEnterprise契約はどうなりますか

公式発表では、既存のEnterpriseサブスクリプションとサポート契約は完全に履行され、通常どおり更新できるとされています。新規のお客様向けに提供されなくなる、という変更です。

Herokuと同じ使い勝手の移行先はありますか

操作感が近いのはRenderやRailwayといったPaaSですが、アドオンの品揃えまで同じではありません。周辺機能をどこまで自前で用意するかは、どの移行先を選んでも検討することになります。

最後に、判断に必要な項目をまとめます。次の6つに答えられれば、動くべきか待つべきかは決まります。

• 今後3年で、プラットフォーム側の新機能を前提にした計画があるか
• 現在の月額と、移行後に想定される月額を比べたか
• データを国内に置く要件があるか
• 使っているアドオンをすべて書き出したか
• 切り替え時にサービスを停止できる時間はどれくらいか
• 移行費用だけでなく、移行後のランニングコストも試算したか

4つ目で手が止まるようであれば、まず棚卸しから始めることをおすすめします。何が動いているか分からない状態では、移行の要否も費用も判断できません。棚卸しの段階からお手伝いできますので、判断に迷っていましたら一度ご相談ください。