Migrer fra Heroku til SIAX

1. 1

   Kortlæg dynos, add-ons og config vars

   Kør heroku ps, heroku addons og heroku config for hver app, og gem outputtet. Notér dynotype og antal pr. procestype samt hvilken plan hver add-on ligger på. Den liste er kravspecifikationen for det nye miljø, og den er næsten altid længere, end teamet regner med.

2. 2

   Erstat buildpacken med en Dockerfile

   Heroku gør meget for jer usynligt: installerer afhængigheder, kompilerer assets, sætter PORT og starter det, der står i Procfile. Alt det skal stå eksplicit i jeres Dockerfile. Bind til den PORT, miljøet angiver, i stedet for en hårdkodet port. Alternativt kan I køre Cloud Native Buildpacks med pack CLI, hvis I vil beholde buildpack-modellen lidt endnu.

3. 3

   Erstat hver add-on for sig

   Gennemgå listen post for post. Heroku Postgres bliver til Managed Postgres. Heroku Data for Redis bliver til Redis eller Valkey på en VPS, som I selv opdaterer og sikkerhedskopierer. Papertrail og lignende log- og uptidstjenester erstattes af vores overvågning til tjek og en logmodtager, I selv vælger. Udgående mail via SendGrid udskiftes med vores mailtjeneste eller en ekstern SMTP-udbyder. Add-ons uden pendant skal enten beholdes som selvstændigt abonnement eller driftes af jer selv.

4. 4

   Migrér Postgres

   Tjek først, hvilke extensions I rent faktisk bruger — ikke hvilke der tilfældigvis er installeret. Tag en pg_dump i custom-format, og kør pg_restore mod den nye instans, og test hele vejen mod en kopi, før I rører produktionen. For databaser over nogle snese gigabyte sætter I logisk replikering op og skifter connection string, når replikaen er ajour. Husk at Herokus DATABASE_URL kan roteres, og at sslmode-indstillingen ofte er forskellig.

5. 5

   Flyt worker-processer og planlagte job

   Hver procestype i Procfile bliver en selvstændig kørsel hos os. Worker-dynos bliver separate containere mod den samme kø. Heroku Scheduler erstattes af cron i containeren eller et planlagt CI-job. Engangskørsler, I lavede med heroku run, kræver en ny rutine — for eksempel en shell i den kørende container eller et manuelt udløst job.

6. 6

   Sæt deploy og hemmeligheder op

   Kobl repoet til Git og CI, så push til main bygger imagen og deployer. Flyt alle config vars til hemmelighedshåndteringen, og rotér dem i forbindelse med flytningen, eftersom de nu har været igennem en eksport. Verificér at appen starter med præcis det sæt variabler, I planlægger at køre i produktion — ikke en delmængde.

7. 7

   Kør parallelt, skift DNS og udfas

   Lad Heroku-appen fortsætte med at tage produktionstrafikken, mens det nye miljø ligger på en staging-adresse. Sammenlign logs, fejlrate og svartider i mindst et døgn med reel trafik. Sæt derefter TTL ned, skift DNS, og lad Heroku køre videre nogle uger endnu, før I skalerer dynos ned til nul og opsiger add-ons.

• Add-ons erstattes ikke med et enkelt klik. Hver tjeneste skal vurderes, erstattes og testes for sig, og nogle har slet ingen god pendant. Det er som regel den største post i tidsplanen.
• Vi har ingen managed Redis som produkt. Har I brug for Redis eller Valkey, kører I den på en VPS fra 59 kr om måneden, med opdateringer, hukommelsesgrænser og backup på jeres eget ansvar.
• Buildpack-magien er usynlig, indtil den forsvinder. Automatisk assetkompilering, PORT-binding og injicerede miljøvariabler holder op med at ske af sig selv og skal skrives eksplicit ind i Dockerfilen.
• Heroku genstartede jeres dynos dagligt. Kode med langsomme memory leaks kan have været skjult af den cyklus og bliver først synlig, når containeren får lov at leve i uger.
• Review apps og pipelines findes ikke som færdig funktion. I kan bygge noget tilsvarende med branch-deploys i CI, men det er arbejde, I skal planlægge ind — ikke en indstilling.

En app med en webproces, en worker, en Postgres, Redis og daglig backup: App Hosting fra 99 kr til webben og 99 kr til workeren, Managed Postgres fra 89 kr, en VPS til Redis fra 59 kr og backup til 19 kr for 100 GB, altså cirka 365 kr om måneden ekskl. moms. Det tilsvarende hos Heroku med to Standard-dynos, Postgres Standard-0 og en Redis-plan ligger på cirka 1.200 til 1.400 kr om måneden til listepris, og priserne ændrer sig løbende.

Kan vi beholde vores buildpacks?

Ikke direkte — vi kører containere. Enten skriver I en Dockerfile, hvilket vi anbefaler på sigt, eller også bygger I et OCI-image fra jeres eksisterende buildpacks med pack CLI. Den anden løsning gør migrationen kortere, men skubber arbejdet foran sig.

Har I managed Redis?

Nej. Redis og Valkey skal køre på en VPS eller dedikeret server. Det bliver billigere end en Heroku-plan, men I overtager driften: opdateringer, hukommelsespolitik, persistens og backup.

Følger vores Postgres-extensions med?

De almindelige gør, herunder pg_stat_statements, pgcrypto, uuid-ossp og PostGIS. Usædvanlige eller Heroku-specifikke extensions skal verificeres, før I planlægger cutover — ikke bagefter. Send listen fra jeres database, så svarer vi konkret.

Hvad gør vi med Heroku Connect eller andre add-ons uden pendant?

Enten beholder I tjenesten som et selvstændigt abonnement hos leverandøren, eller også erstatter I funktionen med noget, I selv drifter. Vi lader ikke som om alt kan flyttes en til en, og den vurdering bør ligge fast, før I beslutter flyttedato.

Andre migreringsguider