Heroku Alternatives
Migrating from Heroku Shield: planning your move without losing compliance posture
Last updated: March 2026
→ For technical migration steps, see Aptible's Heroku Shield migration docs.
→ For the broader migration decision, see Should You Migrate?
Why Shield teams are accelerating migration plans in 2026
Heroku's February 2026 announcement changed the calculus for regulated teams.
The transition to sustaining engineering means no new compliance feature development. The gaps in Shield's compliance posture today are unlikely to close. For teams with growing audit scope, expanding PHI handling, or enterprise customers asking harder security questions, the question has shifted from "whether to migrate" to "when and how."
If you have been weighing this decision, the announcement created a planning urgency that did not exist before.
For context on the announcement itself, see What's Happening at Heroku.
TL;DR: Shield migrations are more complex than standard Heroku migrations, but manageable with structured planning
Shield provides network isolation, HIPAA-supporting controls, and a BAA — all of which require active coordination during migration.
The compliance posture you built on Shield does not automatically transfer to a new platform. It requires deliberate mapping.
Most regulated teams find their compliance posture improves after migration to a purpose-built platform.
A planned migration is far safer than one triggered by an audit, contract failure, or incident.
The question is not whether you can migrate without losing your HIPAA posture. You can. The question is whether you plan for it or find out the hard way.
What makes Shield migration different from standard Heroku migration
Most Heroku migrations are fundamentally a platform abstraction mapping exercise: dynos become containers, buildpacks become Dockerfiles, config vars become secrets management, add-ons get replaced by managed equivalents.
Shield migration includes all of that — plus a compliance continuity problem.
When you run PHI on Heroku Shield, your compliance posture depends on several things Shield provides directly: Private Space network isolation, Shield-specific Postgres with compliant data handling, encryption at rest and in transit, and a Business Associate Agreement with Salesforce. When you leave Shield, each of those dependencies requires an explicit handoff.
That's not a reason to stay. It's a reason to plan.
The five planning areas unique to Shield
1. BAA transition timing
Your current BAA is with Salesforce (Heroku's parent company). When you migrate, that coverage applies only while your PHI remains on Heroku infrastructure. You need an active BAA with your new platform before PHI touches it.
The timing sequence matters:
Execute BAA with target platform before migrating any PHI.
Do not run PHI on the new platform during a trial or proof-of-concept without a signed BAA in place.
Confirm that your new platform's BAA covers the specific services you will use (compute, managed databases, storage, logging).
A gap in BAA coverage — even briefly — is a reportable event if something goes wrong during that period. Get the paperwork done first.
2. Network isolation mapping
Shield Private Spaces provide dedicated, isolated compute environments with private networking. That isolation is part of how you demonstrate HIPAA technical safeguard compliance.
On your target platform, you need equivalent isolation. What that looks like depends on the platform:
On a compliance-first PaaS (Aptible), shared-nothing AWS isolation is the default model. You are not configuring this yourself — it is the baseline platform behavior.
On DIY AWS, you are responsible for VPC design, security groups, IAM policies, and private endpoint configuration. This is doable, but it requires deliberate architecture work.
On general-purpose PaaS alternatives, isolation models vary significantly. Some provide dedicated environments; others do not. Verify before you commit.
If you cannot clearly explain what separates your PHI workload from other tenants on the new platform, that is an audit problem waiting to happen.
3. PHI database migration
Shield Postgres databases carry PHI. The migration strategy needs to treat them accordingly.
Standard Heroku Postgres migration choices apply (dump and restore for acceptable downtime; logical replication for minimal-downtime moves), but with additional requirements:
The dump or replication stream itself contains PHI. Ensure it travels over encrypted channels and is not stored unencrypted in transit.
The target database must be covered under your BAA before you restore PHI into it.
Validate encryption at rest on the target database before migrating data.
After migration, verify that access controls are configured correctly. PHI databases should not be accessible to unauthorized services or users by default.
See the technical steps for Postgres migration: Aptible's Heroku Shield migration docs
4. Audit trail continuity
Heroku Shield generates compliance-supporting logs and audit evidence. When you migrate, you need to preserve that history and establish continuity on the new platform.
Before migration:
Export Shield audit logs and store them for the duration required by your retention policy.
Document your current environment configuration, access controls, and isolation setup. This becomes the "before" state in your audit record.
Capture deployment history, configuration change history, and access logs from your Shield environment.
After migration:
Confirm that your new platform generates equivalent audit evidence.
Update your security policies and compliance documentation to reflect the new platform.
Run a post-migration audit validation before closing out the migration project.
Gaps in audit trail continuity are one of the most common compliance issues in regulated platform migrations. Build the evidence collection into the migration plan, not as an afterthought.
5. Worker, job, and Redis coordination
Background workers and Redis-backed job queues that touch PHI require careful sequencing during cutover. Running workers split across two platforms — with some jobs processing on Heroku and others on the new platform — creates data integrity and audit trail problems.
The safest approach:
Drain the job queue on Heroku before enabling workers on the new platform.
Validate that no jobs are in-flight when you cut over.
If using Redis for job queuing, treat the Redis migration as a distinct step with its own validation.
This is the part of Shield migrations that teams most commonly underestimate.
Timing your migration relative to audit cycles
Regulated teams operate on audit cycles. The timing of your migration should account for them.
Migrating in the middle of an active audit is inadvisable. You introduce configuration changes, new evidence sources, and new documentation requirements at exactly the wrong time.
The best migration timing is:
After a major audit closes, giving you runway before the next one
At least 90 days before a planned SOC 2 audit or HITRUST assessment, so the new platform's controls have time to demonstrate continuity
During a period of lower PHI volume or with a maintenance window that allows for reduced-traffic cutover
If you are anticipating an enterprise deal that will trigger a security review, migrate before that deal closes, not after.
What compliance looks like after migration
Most regulated teams that migrate off Shield to a purpose-built compliance platform find their overall compliance posture improves. The reasons are structural.
Shield requires you to layer compliance evidence on top of a platform that was not originally designed for it. Audit preparation involves mapping Heroku's controls to your own policies, explaining multi-tenant boundaries to auditors, and manually generating evidence that more opinionated platforms produce automatically.
On a platform designed for regulated workloads:
Isolation boundaries are explicit and documentable by default.
Infrastructure actions are logged and retained without custom configuration.
Shared responsibility boundaries are clearer, which means audit evidence generation is more straightforward.
BAA terms are typically written with regulated use cases in mind.
A well-planned migration is not just an infrastructure move. For most Shield teams, it marks the point where compliance transitions from a manual exercise to a platform-enforced default.
Choosing a target platform for PHI workloads
Not every Heroku alternative is appropriate for HIPAA workloads.
The non-negotiables
Before evaluating any platform, confirm:
BAA availability: is a Business Associate Agreement available, and does it cover all services you will use?
Isolation model: how is your workload separated from other tenants? Can you explain this to an auditor?
Encryption: is data encrypted at rest and in transit by default, or is this a configuration you own?
Audit logging: what infrastructure-level events are logged and for how long?
Access controls: does the platform support SSO, MFA, and role-based access appropriate for your compliance requirements?
Compliance-first platforms
Purpose-built platforms like Aptible enforce these controls at the infrastructure level. Compliance posture is not a configuration option — it is the baseline. This reduces the amount of compliance work your team owns and simplifies audit preparation significantly.
→ See: Heroku vs. Aptible
DIY cloud (AWS, GCP, Azure)
Cloud providers can support HIPAA workloads, and BAAs are available. But the shared responsibility model means you own the configuration, validation, and ongoing enforcement of every security and compliance control. For most regulated startups, this is more platform engineering than they can absorb without dedicated headcount.
→ See: DIY Cloud
Heroku-like PaaS alternatives
Most Heroku-like PaaS alternatives are not built for regulated workloads. Some offer BAAs; fewer have isolation models suitable for PHI. Evaluate carefully before committing, and confirm BAA coverage and isolation posture before any PHI touches the platform.
→ See: PaaS Alternatives
When to start planning
Shield teams should start planning a migration when any of these conditions apply:
Enterprise deals are starting to include security questionnaires that expose weaknesses in your current isolation or audit evidence posture.
Audit complexity is growing — more PHI scope, more third-party reviews, more evidence requests.
Your compliance team is spending significant time on documentation that a different platform would produce automatically.
Heroku's sustaining engineering posture means you cannot expect the compliance gaps you have identified to close.
→ See: What's Happening at Heroku, Heroku and HIPAA
You do not need a crisis to justify planning. A structured migration done ahead of compliance pressure is significantly cheaper (in time, money, and risk) than one triggered by an audit finding or a lost enterprise deal.
Pre-migration checklist for Shield environments
Before beginning a Shield migration:
BAA with target platform signed
Audit logs from Shield environment exported and retained
Environment configuration documented
Database migration strategy defined (dump/restore vs. logical replication)
Database encryption and access controls on target platform validated
Worker and job queue coordination plan defined
Redis migration sequenced
DNS cutover plan established (low TTL set in advance)
Rollback triggers defined and communicated
Migration timing aligned with audit cycle
Post-migration audit validation scheduled
Common questions Shield teams ask before starting
Can we run a PoC on the new platform before migrating PHI?
Yes, and you should. Run the PoC with synthetic or de-identified data. The BAA should still be signed before you run the PoC if there is any chance real PHI will be in scope. In practice, most teams sign the BAA, run the PoC with non-PHI data, validate their compliance requirements, and then proceed with PHI migration in a later phase.
How long does migration typically take for a Shield workload?
Four to eight weeks is a realistic minimum for a well-planned migration with a small to medium Shield environment. Larger environments, multiple services, high data volumes, or complex networking extend the timeline. Teams that try to compress below four weeks often discover they are skipping compliance steps rather than moving efficiently.
Do we need to notify patients or regulators during the migration?
Typically no for a platform migration, assuming no PHI is exposed, lost, or accessed impermissibly during the process. However, your HIPAA compliance counsel should confirm this based on your specific situation.
What happens to our existing audit history during migration?
Your existing audit logs stay in Heroku. Export what you need before you leave. Heroku does not guarantee that you will have access to historical audit data after you wind down your environment. Plan accordingly, and document the handoff as part of your migration evidence.
Can we run the old Shield environment and the new environment in parallel during migration?
Yes, and this is strongly recommended. Running environments in parallel during the migration window gives you a rollback option and lets you validate the new environment under real traffic conditions before committing fully. It increases cost during the overlap period but reduces risk substantially.
Technical steps
This chapter covers planning. For the technical migration steps specific to Heroku Shield environments (including Private Space networking, Shield database migration, endpoint cutover, and worker sequencing) see Aptible's Heroku Shield migration docs.
Next steps
If you haven't chosen a target platform yet: Read Compare Platforms to evaluate your options. For regulated workloads, the shortlist is typically Aptible, Render's HIPAA workspace, or AWS. See Heroku vs. Aptible if compliance infrastructure is the primary driver.
If you're ready to plan the technical migration: See Aptible's Heroku Shield migration docs for the full technical breakdown: Private Space networking, Shield database migration, endpoint cutover, and worker sequencing.
If you're still deciding whether the migration is worth it: Read Should You Migrate? and Heroku and HIPAA for the compliance-specific forcing functions that typically drive Shield teams toward a migration decision.
Heroku Alternatives
Migrating from Heroku Shield: planning your move without losing compliance posture
Last updated: March 2026
→ For technical migration steps, see Aptible's Heroku Shield migration docs.
→ For the broader migration decision, see Should You Migrate?
Why Shield teams are accelerating migration plans in 2026
Heroku's February 2026 announcement changed the calculus for regulated teams.
The transition to sustaining engineering means no new compliance feature development. The gaps in Shield's compliance posture today are unlikely to close. For teams with growing audit scope, expanding PHI handling, or enterprise customers asking harder security questions, the question has shifted from "whether to migrate" to "when and how."
If you have been weighing this decision, the announcement created a planning urgency that did not exist before.
For context on the announcement itself, see What's Happening at Heroku.
TL;DR: Shield migrations are more complex than standard Heroku migrations, but manageable with structured planning
Shield provides network isolation, HIPAA-supporting controls, and a BAA — all of which require active coordination during migration.
The compliance posture you built on Shield does not automatically transfer to a new platform. It requires deliberate mapping.
Most regulated teams find their compliance posture improves after migration to a purpose-built platform.
A planned migration is far safer than one triggered by an audit, contract failure, or incident.
The question is not whether you can migrate without losing your HIPAA posture. You can. The question is whether you plan for it or find out the hard way.
What makes Shield migration different from standard Heroku migration
Most Heroku migrations are fundamentally a platform abstraction mapping exercise: dynos become containers, buildpacks become Dockerfiles, config vars become secrets management, add-ons get replaced by managed equivalents.
Shield migration includes all of that — plus a compliance continuity problem.
When you run PHI on Heroku Shield, your compliance posture depends on several things Shield provides directly: Private Space network isolation, Shield-specific Postgres with compliant data handling, encryption at rest and in transit, and a Business Associate Agreement with Salesforce. When you leave Shield, each of those dependencies requires an explicit handoff.
That's not a reason to stay. It's a reason to plan.
The five planning areas unique to Shield
1. BAA transition timing
Your current BAA is with Salesforce (Heroku's parent company). When you migrate, that coverage applies only while your PHI remains on Heroku infrastructure. You need an active BAA with your new platform before PHI touches it.
The timing sequence matters:
Execute BAA with target platform before migrating any PHI.
Do not run PHI on the new platform during a trial or proof-of-concept without a signed BAA in place.
Confirm that your new platform's BAA covers the specific services you will use (compute, managed databases, storage, logging).
A gap in BAA coverage — even briefly — is a reportable event if something goes wrong during that period. Get the paperwork done first.
2. Network isolation mapping
Shield Private Spaces provide dedicated, isolated compute environments with private networking. That isolation is part of how you demonstrate HIPAA technical safeguard compliance.
On your target platform, you need equivalent isolation. What that looks like depends on the platform:
On a compliance-first PaaS (Aptible), shared-nothing AWS isolation is the default model. You are not configuring this yourself — it is the baseline platform behavior.
On DIY AWS, you are responsible for VPC design, security groups, IAM policies, and private endpoint configuration. This is doable, but it requires deliberate architecture work.
On general-purpose PaaS alternatives, isolation models vary significantly. Some provide dedicated environments; others do not. Verify before you commit.
If you cannot clearly explain what separates your PHI workload from other tenants on the new platform, that is an audit problem waiting to happen.
3. PHI database migration
Shield Postgres databases carry PHI. The migration strategy needs to treat them accordingly.
Standard Heroku Postgres migration choices apply (dump and restore for acceptable downtime; logical replication for minimal-downtime moves), but with additional requirements:
The dump or replication stream itself contains PHI. Ensure it travels over encrypted channels and is not stored unencrypted in transit.
The target database must be covered under your BAA before you restore PHI into it.
Validate encryption at rest on the target database before migrating data.
After migration, verify that access controls are configured correctly. PHI databases should not be accessible to unauthorized services or users by default.
See the technical steps for Postgres migration: Aptible's Heroku Shield migration docs
4. Audit trail continuity
Heroku Shield generates compliance-supporting logs and audit evidence. When you migrate, you need to preserve that history and establish continuity on the new platform.
Before migration:
Export Shield audit logs and store them for the duration required by your retention policy.
Document your current environment configuration, access controls, and isolation setup. This becomes the "before" state in your audit record.
Capture deployment history, configuration change history, and access logs from your Shield environment.
After migration:
Confirm that your new platform generates equivalent audit evidence.
Update your security policies and compliance documentation to reflect the new platform.
Run a post-migration audit validation before closing out the migration project.
Gaps in audit trail continuity are one of the most common compliance issues in regulated platform migrations. Build the evidence collection into the migration plan, not as an afterthought.
5. Worker, job, and Redis coordination
Background workers and Redis-backed job queues that touch PHI require careful sequencing during cutover. Running workers split across two platforms — with some jobs processing on Heroku and others on the new platform — creates data integrity and audit trail problems.
The safest approach:
Drain the job queue on Heroku before enabling workers on the new platform.
Validate that no jobs are in-flight when you cut over.
If using Redis for job queuing, treat the Redis migration as a distinct step with its own validation.
This is the part of Shield migrations that teams most commonly underestimate.
Timing your migration relative to audit cycles
Regulated teams operate on audit cycles. The timing of your migration should account for them.
Migrating in the middle of an active audit is inadvisable. You introduce configuration changes, new evidence sources, and new documentation requirements at exactly the wrong time.
The best migration timing is:
After a major audit closes, giving you runway before the next one
At least 90 days before a planned SOC 2 audit or HITRUST assessment, so the new platform's controls have time to demonstrate continuity
During a period of lower PHI volume or with a maintenance window that allows for reduced-traffic cutover
If you are anticipating an enterprise deal that will trigger a security review, migrate before that deal closes, not after.
What compliance looks like after migration
Most regulated teams that migrate off Shield to a purpose-built compliance platform find their overall compliance posture improves. The reasons are structural.
Shield requires you to layer compliance evidence on top of a platform that was not originally designed for it. Audit preparation involves mapping Heroku's controls to your own policies, explaining multi-tenant boundaries to auditors, and manually generating evidence that more opinionated platforms produce automatically.
On a platform designed for regulated workloads:
Isolation boundaries are explicit and documentable by default.
Infrastructure actions are logged and retained without custom configuration.
Shared responsibility boundaries are clearer, which means audit evidence generation is more straightforward.
BAA terms are typically written with regulated use cases in mind.
A well-planned migration is not just an infrastructure move. For most Shield teams, it marks the point where compliance transitions from a manual exercise to a platform-enforced default.
Choosing a target platform for PHI workloads
Not every Heroku alternative is appropriate for HIPAA workloads.
The non-negotiables
Before evaluating any platform, confirm:
BAA availability: is a Business Associate Agreement available, and does it cover all services you will use?
Isolation model: how is your workload separated from other tenants? Can you explain this to an auditor?
Encryption: is data encrypted at rest and in transit by default, or is this a configuration you own?
Audit logging: what infrastructure-level events are logged and for how long?
Access controls: does the platform support SSO, MFA, and role-based access appropriate for your compliance requirements?
Compliance-first platforms
Purpose-built platforms like Aptible enforce these controls at the infrastructure level. Compliance posture is not a configuration option — it is the baseline. This reduces the amount of compliance work your team owns and simplifies audit preparation significantly.
→ See: Heroku vs. Aptible
DIY cloud (AWS, GCP, Azure)
Cloud providers can support HIPAA workloads, and BAAs are available. But the shared responsibility model means you own the configuration, validation, and ongoing enforcement of every security and compliance control. For most regulated startups, this is more platform engineering than they can absorb without dedicated headcount.
→ See: DIY Cloud
Heroku-like PaaS alternatives
Most Heroku-like PaaS alternatives are not built for regulated workloads. Some offer BAAs; fewer have isolation models suitable for PHI. Evaluate carefully before committing, and confirm BAA coverage and isolation posture before any PHI touches the platform.
→ See: PaaS Alternatives
When to start planning
Shield teams should start planning a migration when any of these conditions apply:
Enterprise deals are starting to include security questionnaires that expose weaknesses in your current isolation or audit evidence posture.
Audit complexity is growing — more PHI scope, more third-party reviews, more evidence requests.
Your compliance team is spending significant time on documentation that a different platform would produce automatically.
Heroku's sustaining engineering posture means you cannot expect the compliance gaps you have identified to close.
→ See: What's Happening at Heroku, Heroku and HIPAA
You do not need a crisis to justify planning. A structured migration done ahead of compliance pressure is significantly cheaper (in time, money, and risk) than one triggered by an audit finding or a lost enterprise deal.
Pre-migration checklist for Shield environments
Before beginning a Shield migration:
BAA with target platform signed
Audit logs from Shield environment exported and retained
Environment configuration documented
Database migration strategy defined (dump/restore vs. logical replication)
Database encryption and access controls on target platform validated
Worker and job queue coordination plan defined
Redis migration sequenced
DNS cutover plan established (low TTL set in advance)
Rollback triggers defined and communicated
Migration timing aligned with audit cycle
Post-migration audit validation scheduled
Common questions Shield teams ask before starting
Can we run a PoC on the new platform before migrating PHI?
Yes, and you should. Run the PoC with synthetic or de-identified data. The BAA should still be signed before you run the PoC if there is any chance real PHI will be in scope. In practice, most teams sign the BAA, run the PoC with non-PHI data, validate their compliance requirements, and then proceed with PHI migration in a later phase.
How long does migration typically take for a Shield workload?
Four to eight weeks is a realistic minimum for a well-planned migration with a small to medium Shield environment. Larger environments, multiple services, high data volumes, or complex networking extend the timeline. Teams that try to compress below four weeks often discover they are skipping compliance steps rather than moving efficiently.
Do we need to notify patients or regulators during the migration?
Typically no for a platform migration, assuming no PHI is exposed, lost, or accessed impermissibly during the process. However, your HIPAA compliance counsel should confirm this based on your specific situation.
What happens to our existing audit history during migration?
Your existing audit logs stay in Heroku. Export what you need before you leave. Heroku does not guarantee that you will have access to historical audit data after you wind down your environment. Plan accordingly, and document the handoff as part of your migration evidence.
Can we run the old Shield environment and the new environment in parallel during migration?
Yes, and this is strongly recommended. Running environments in parallel during the migration window gives you a rollback option and lets you validate the new environment under real traffic conditions before committing fully. It increases cost during the overlap period but reduces risk substantially.
Technical steps
This chapter covers planning. For the technical migration steps specific to Heroku Shield environments (including Private Space networking, Shield database migration, endpoint cutover, and worker sequencing) see Aptible's Heroku Shield migration docs.
Next steps
If you haven't chosen a target platform yet: Read Compare Platforms to evaluate your options. For regulated workloads, the shortlist is typically Aptible, Render's HIPAA workspace, or AWS. See Heroku vs. Aptible if compliance infrastructure is the primary driver.
If you're ready to plan the technical migration: See Aptible's Heroku Shield migration docs for the full technical breakdown: Private Space networking, Shield database migration, endpoint cutover, and worker sequencing.
If you're still deciding whether the migration is worth it: Read Should You Migrate? and Heroku and HIPAA for the compliance-specific forcing functions that typically drive Shield teams toward a migration decision.
Migrating from Heroku Shield: planning your move without losing compliance posture
Last updated: March 2026
→ For technical migration steps, see Aptible's Heroku Shield migration docs.
→ For the broader migration decision, see Should You Migrate?
Why Shield teams are accelerating migration plans in 2026
Heroku's February 2026 announcement changed the calculus for regulated teams.
The transition to sustaining engineering means no new compliance feature development. The gaps in Shield's compliance posture today are unlikely to close. For teams with growing audit scope, expanding PHI handling, or enterprise customers asking harder security questions, the question has shifted from "whether to migrate" to "when and how."
If you have been weighing this decision, the announcement created a planning urgency that did not exist before.
For context on the announcement itself, see What's Happening at Heroku.
TL;DR: Shield migrations are more complex than standard Heroku migrations, but manageable with structured planning
Shield provides network isolation, HIPAA-supporting controls, and a BAA — all of which require active coordination during migration.
The compliance posture you built on Shield does not automatically transfer to a new platform. It requires deliberate mapping.
Most regulated teams find their compliance posture improves after migration to a purpose-built platform.
A planned migration is far safer than one triggered by an audit, contract failure, or incident.
The question is not whether you can migrate without losing your HIPAA posture. You can. The question is whether you plan for it or find out the hard way.
What makes Shield migration different from standard Heroku migration
Most Heroku migrations are fundamentally a platform abstraction mapping exercise: dynos become containers, buildpacks become Dockerfiles, config vars become secrets management, add-ons get replaced by managed equivalents.
Shield migration includes all of that — plus a compliance continuity problem.
When you run PHI on Heroku Shield, your compliance posture depends on several things Shield provides directly: Private Space network isolation, Shield-specific Postgres with compliant data handling, encryption at rest and in transit, and a Business Associate Agreement with Salesforce. When you leave Shield, each of those dependencies requires an explicit handoff.
That's not a reason to stay. It's a reason to plan.
The five planning areas unique to Shield
1. BAA transition timing
Your current BAA is with Salesforce (Heroku's parent company). When you migrate, that coverage applies only while your PHI remains on Heroku infrastructure. You need an active BAA with your new platform before PHI touches it.
The timing sequence matters:
Execute BAA with target platform before migrating any PHI.
Do not run PHI on the new platform during a trial or proof-of-concept without a signed BAA in place.
Confirm that your new platform's BAA covers the specific services you will use (compute, managed databases, storage, logging).
A gap in BAA coverage — even briefly — is a reportable event if something goes wrong during that period. Get the paperwork done first.
2. Network isolation mapping
Shield Private Spaces provide dedicated, isolated compute environments with private networking. That isolation is part of how you demonstrate HIPAA technical safeguard compliance.
On your target platform, you need equivalent isolation. What that looks like depends on the platform:
On a compliance-first PaaS (Aptible), shared-nothing AWS isolation is the default model. You are not configuring this yourself — it is the baseline platform behavior.
On DIY AWS, you are responsible for VPC design, security groups, IAM policies, and private endpoint configuration. This is doable, but it requires deliberate architecture work.
On general-purpose PaaS alternatives, isolation models vary significantly. Some provide dedicated environments; others do not. Verify before you commit.
If you cannot clearly explain what separates your PHI workload from other tenants on the new platform, that is an audit problem waiting to happen.
3. PHI database migration
Shield Postgres databases carry PHI. The migration strategy needs to treat them accordingly.
Standard Heroku Postgres migration choices apply (dump and restore for acceptable downtime; logical replication for minimal-downtime moves), but with additional requirements:
The dump or replication stream itself contains PHI. Ensure it travels over encrypted channels and is not stored unencrypted in transit.
The target database must be covered under your BAA before you restore PHI into it.
Validate encryption at rest on the target database before migrating data.
After migration, verify that access controls are configured correctly. PHI databases should not be accessible to unauthorized services or users by default.
See the technical steps for Postgres migration: Aptible's Heroku Shield migration docs
4. Audit trail continuity
Heroku Shield generates compliance-supporting logs and audit evidence. When you migrate, you need to preserve that history and establish continuity on the new platform.
Before migration:
Export Shield audit logs and store them for the duration required by your retention policy.
Document your current environment configuration, access controls, and isolation setup. This becomes the "before" state in your audit record.
Capture deployment history, configuration change history, and access logs from your Shield environment.
After migration:
Confirm that your new platform generates equivalent audit evidence.
Update your security policies and compliance documentation to reflect the new platform.
Run a post-migration audit validation before closing out the migration project.
Gaps in audit trail continuity are one of the most common compliance issues in regulated platform migrations. Build the evidence collection into the migration plan, not as an afterthought.
5. Worker, job, and Redis coordination
Background workers and Redis-backed job queues that touch PHI require careful sequencing during cutover. Running workers split across two platforms — with some jobs processing on Heroku and others on the new platform — creates data integrity and audit trail problems.
The safest approach:
Drain the job queue on Heroku before enabling workers on the new platform.
Validate that no jobs are in-flight when you cut over.
If using Redis for job queuing, treat the Redis migration as a distinct step with its own validation.
This is the part of Shield migrations that teams most commonly underestimate.
Timing your migration relative to audit cycles
Regulated teams operate on audit cycles. The timing of your migration should account for them.
Migrating in the middle of an active audit is inadvisable. You introduce configuration changes, new evidence sources, and new documentation requirements at exactly the wrong time.
The best migration timing is:
After a major audit closes, giving you runway before the next one
At least 90 days before a planned SOC 2 audit or HITRUST assessment, so the new platform's controls have time to demonstrate continuity
During a period of lower PHI volume or with a maintenance window that allows for reduced-traffic cutover
If you are anticipating an enterprise deal that will trigger a security review, migrate before that deal closes, not after.
What compliance looks like after migration
Most regulated teams that migrate off Shield to a purpose-built compliance platform find their overall compliance posture improves. The reasons are structural.
Shield requires you to layer compliance evidence on top of a platform that was not originally designed for it. Audit preparation involves mapping Heroku's controls to your own policies, explaining multi-tenant boundaries to auditors, and manually generating evidence that more opinionated platforms produce automatically.
On a platform designed for regulated workloads:
Isolation boundaries are explicit and documentable by default.
Infrastructure actions are logged and retained without custom configuration.
Shared responsibility boundaries are clearer, which means audit evidence generation is more straightforward.
BAA terms are typically written with regulated use cases in mind.
A well-planned migration is not just an infrastructure move. For most Shield teams, it marks the point where compliance transitions from a manual exercise to a platform-enforced default.
Choosing a target platform for PHI workloads
Not every Heroku alternative is appropriate for HIPAA workloads.
The non-negotiables
Before evaluating any platform, confirm:
BAA availability: is a Business Associate Agreement available, and does it cover all services you will use?
Isolation model: how is your workload separated from other tenants? Can you explain this to an auditor?
Encryption: is data encrypted at rest and in transit by default, or is this a configuration you own?
Audit logging: what infrastructure-level events are logged and for how long?
Access controls: does the platform support SSO, MFA, and role-based access appropriate for your compliance requirements?
Compliance-first platforms
Purpose-built platforms like Aptible enforce these controls at the infrastructure level. Compliance posture is not a configuration option — it is the baseline. This reduces the amount of compliance work your team owns and simplifies audit preparation significantly.
→ See: Heroku vs. Aptible
DIY cloud (AWS, GCP, Azure)
Cloud providers can support HIPAA workloads, and BAAs are available. But the shared responsibility model means you own the configuration, validation, and ongoing enforcement of every security and compliance control. For most regulated startups, this is more platform engineering than they can absorb without dedicated headcount.
→ See: DIY Cloud
Heroku-like PaaS alternatives
Most Heroku-like PaaS alternatives are not built for regulated workloads. Some offer BAAs; fewer have isolation models suitable for PHI. Evaluate carefully before committing, and confirm BAA coverage and isolation posture before any PHI touches the platform.
→ See: PaaS Alternatives
When to start planning
Shield teams should start planning a migration when any of these conditions apply:
Enterprise deals are starting to include security questionnaires that expose weaknesses in your current isolation or audit evidence posture.
Audit complexity is growing — more PHI scope, more third-party reviews, more evidence requests.
Your compliance team is spending significant time on documentation that a different platform would produce automatically.
Heroku's sustaining engineering posture means you cannot expect the compliance gaps you have identified to close.
→ See: What's Happening at Heroku, Heroku and HIPAA
You do not need a crisis to justify planning. A structured migration done ahead of compliance pressure is significantly cheaper (in time, money, and risk) than one triggered by an audit finding or a lost enterprise deal.
Pre-migration checklist for Shield environments
Before beginning a Shield migration:
BAA with target platform signed
Audit logs from Shield environment exported and retained
Environment configuration documented
Database migration strategy defined (dump/restore vs. logical replication)
Database encryption and access controls on target platform validated
Worker and job queue coordination plan defined
Redis migration sequenced
DNS cutover plan established (low TTL set in advance)
Rollback triggers defined and communicated
Migration timing aligned with audit cycle
Post-migration audit validation scheduled
Common questions Shield teams ask before starting
Can we run a PoC on the new platform before migrating PHI?
Yes, and you should. Run the PoC with synthetic or de-identified data. The BAA should still be signed before you run the PoC if there is any chance real PHI will be in scope. In practice, most teams sign the BAA, run the PoC with non-PHI data, validate their compliance requirements, and then proceed with PHI migration in a later phase.
How long does migration typically take for a Shield workload?
Four to eight weeks is a realistic minimum for a well-planned migration with a small to medium Shield environment. Larger environments, multiple services, high data volumes, or complex networking extend the timeline. Teams that try to compress below four weeks often discover they are skipping compliance steps rather than moving efficiently.
Do we need to notify patients or regulators during the migration?
Typically no for a platform migration, assuming no PHI is exposed, lost, or accessed impermissibly during the process. However, your HIPAA compliance counsel should confirm this based on your specific situation.
What happens to our existing audit history during migration?
Your existing audit logs stay in Heroku. Export what you need before you leave. Heroku does not guarantee that you will have access to historical audit data after you wind down your environment. Plan accordingly, and document the handoff as part of your migration evidence.
Can we run the old Shield environment and the new environment in parallel during migration?
Yes, and this is strongly recommended. Running environments in parallel during the migration window gives you a rollback option and lets you validate the new environment under real traffic conditions before committing fully. It increases cost during the overlap period but reduces risk substantially.
Technical steps
This chapter covers planning. For the technical migration steps specific to Heroku Shield environments (including Private Space networking, Shield database migration, endpoint cutover, and worker sequencing) see Aptible's Heroku Shield migration docs.
Next steps
If you haven't chosen a target platform yet: Read Compare Platforms to evaluate your options. For regulated workloads, the shortlist is typically Aptible, Render's HIPAA workspace, or AWS. See Heroku vs. Aptible if compliance infrastructure is the primary driver.
If you're ready to plan the technical migration: See Aptible's Heroku Shield migration docs for the full technical breakdown: Private Space networking, Shield database migration, endpoint cutover, and worker sequencing.
If you're still deciding whether the migration is worth it: Read Should You Migrate? and Heroku and HIPAA for the compliance-specific forcing functions that typically drive Shield teams toward a migration decision.
548 Market St #75826 San Francisco, CA 94104
© 2026. All rights reserved. Privacy Policy
548 Market St #75826 San Francisco, CA 94104
© 2026. All rights reserved. Privacy Policy