他プラットフォームから簡単に・迅速に移行可能

移行は数時間〜数日で完了。<br>数ヶ月かかるようなプロジェクトではありません。

Choose your migration path

Whether you're coming from Heroku or another cloud platform, you can get Build running alongside your existing infrastructure before moving production.

Moving from Heroku

Connect your Heroku account and automatically import your apps, environment variables, add-on configuration and pipelines. Get your application running on Build in minutes.

See the Heroku migration

Moving from another platform

Build supports Buildpacks and Dockerfiles, so many applications can move without code changes. Our engineers help you plan the migration and get everything running.

See how migrations work

Migrate your Heroku app in minutes

Build connects directly to Heroku and imports your existing configuration, removing much of the manual setup.

1

Herokuアカウントを接続

既存のアプリ、環境変数、アドオン設定を自動的にインポートします。

2

ビルド設定を確認

BuildがBuildpackと環境を自動検出し、あとはインポートを承認するだけ。<br>必要に応じてカスタマイズも可能。

3

準備ができたら切り替え

HerokuとBuildを並行稼働。検証、テスト後、確信が持てたらDNSを切り替え。<br>ダウンタイムなしの移行を実現。

4

Deploy alongside Heroku

Run your application on Build while Heroku continues serving production. Test and validate it, then switch traffic when you are ready.

Case study

Baremetrics moved beyond Heroku

Baremetrics migrated using Build's direct Heroku integration, moving workloads one component at a time without downtime.

Today, Baremetrics runs deployments of more than 200 dynos and processes 32,000 database writes per second on Build.

Read the Baremetrics case study
The Build team are super responsive and eager to work with us to ensure our infrastructure needs are met as we scale. Quick to get on a call and offer proactive solutions to any issues we may see on the horizon.
Luke Marshall
CEO, Baremetrics

Migrating from Render, Vercel, AWS or elsewhere?

Others Subtitle

Many applications can move to Build without a rewrite. We support Buildpacks and Dockerfiles, so you can often keep your existing build configuration.

The main work is usually migrating your services, databases, networking and other dependencies. Our engineers help you map these out and plan the move.

1

Review your current setup

We review your application, services, data and dependencies, then put together a migration plan and timeline.

2

Deploy on Build

Get your application and supporting services running on Build while your existing platform continues serving production.

3

Test and switch over

Validate your application on Build, then move production traffic when you're ready. Migrate everything together or service by service, depending on your setup.

Case study

Saambaa runs 50 million requests a day on Build

Saambaa moved from its previous infrastructure to Build, where it now serves 50 million requests a day.

With less infrastructure to manage, its engineers can spend more time building geographic products, publisher tools and AI capabilities.

Read the Saambaa case study
Build provides peace of mind through reliable, scalable infrastructure. Their support network is straightforward and responsive. We've eliminated the runaround and communication gaps we dealt with in the past. Build feels like a true partner and gives us a level of confidence we've never had before.
Scott Kurth
VP Engineering, Saambaa
Engineer-led migration support

Your migration. Backed by Build engineers.

Run the migration yourself with help when you need it, or have our engineers take a more active role. We support your team from initial planning through to production.

Engineer-led migration support is included with every Enterprise plan.

As hands-on as you need
Run the migration yourself, work together with our engineers or have us take on more of the work.
Direct access to engineers
Get answers directly from Build engineers who know the platform inside out.
Migrate on your schedule
Plan the move around your team's priorities and release schedule.
Support after migration
Our engineers remain available once your applications are running in production.

Risk Title

Risk Subtitle

Risk Stage Build
→
Risk Stage Data
→
Risk Stage Cutover
→
Risk Stage Rollback

Risk Stage Build. Risk Body Build

Risk Stage Data. Risk Body Data

Risk Stage Cutover. Risk Body Cutover

Risk Stage Rollback. Risk Body Rollback

よくある質問

これまでのHerokuのワークフローはそのまま使えますか

はい、日々のワークフローはそのまま引き継がれます。デプロイはGitへのプッシュで行い、Procfileとプロセスタイプは変更なく動作します。config vars、パイプライン、レビュー環境も同じ名称のまま同じように使えます。

Build への移行にはどれくらいかかりますか

Heroku からの移行は、専用の連携機能を使えば数分です。既存のアプリ、環境変数、アドオンの設定が自動で Build に取り込まれます。検証と切り替えには通常、数時間から数日かかります。期間は、両方のプラットフォームを並行して動かす長さによって変わります。他のプラットフォームからの移行はもう少し手間がかかることがありますが、エンジニアが主導する移行支援を利用できます。

移行にあたってコードを変更する必要はありますか

多くの場合、必要ありません。Build は buildpack と Dockerfile に対応しているため、コードを変えずに移行できるチームが大半です。

Heroku から自動で取り込まれるものは何ですか

Heroku アカウントを Build につなぐと、アプリ、環境変数、アドオンの設定、パイプラインの構成が自動で取り込まれます。検証中も Heroku のアプリは動き続け、切り替えるかどうかを決めるのはお客様です。

Build と現在のプラットフォームを並行して動かせますか

はい、動かせます。現在のプラットフォームでトラフィックを処理したまま Build を並行して動かし、確信が持てた時点で DNS を切り替えられます。並行運用は推奨する進め方で、多くの移行がこの方法でダウンタイムを完全に避けています。

移行作業は自社で進めるのですか、それとも Build が対応するのですか

Enterprise プランには、エンジニアが主導する移行支援が標準で含まれます。ドキュメントを渡して終わりにせず、Build のエンジニアがチームと並んで作業します。作業の時期と切り替えのタイミングは、お客様が決めます。