Inventariseer het project voordat u de verhuizing boekt
Gebruik een illustratieve enquiry-website op client.example.com: redacteuren publiceren projectpagina's, bezoekers uploaden een brief en een geplande taak exporteert enquiries naar een clientsysteem. Het verhuizen van de publieke pagina's zou slechts een deel van de klus dekken. Bevestig geautoriseerde toegang tot de bron en bestemming, domeinbesturing en herstelkopieën voordat u een datum vastlegt.
Leg voor elke component de eigenaar, versie, locatie, afhankelijkheden en acceptatiecontrole vast. Houd locaties van inloggegevens in de inventaris; bewaar wachtwoorden en privésleutels in de goedgekeurde secret store.
Scroll horizontaal voor alle tabelkolommen.
| Component | Vastleggen vóór verhuizing | Wie bevestigt het |
|---|---|---|
| Domein en DNS | Registrar, DNS-operator, huidige records en TTL's | Eigenaar van clientaccount |
| Applicatie | Release, runtime, extensies en deploymentmethode | Onderhouder bij het bureau |
| Data en uploads | Database, uploadpaden, back-upmethode en laatst bruikbare kopie | Data-operator |
| Formulieren en integraties | Ontvangers, webhook-endpoints en toegestane testbestemming | Eigenaar van de clientworkflow |
| Gepland werk | Cron of scheduler, tijdzone, wachtrij en laatste geslaagde run | Onderhouder bij het bureau |
Bewijs de herstelkopie voordat u de productie aanraakt
Herstel naar een afzonderlijke testbestemming, nooit over de live-database. Voor PostgreSQL vertegenwoordigt een SQL-dump een consistente databasesnapshot, maar een dump van één database bevat geen clusterbrede rollen of tablespaces. Leg de ondersteunende objecten vast die uw applicatie vereist. Die databasesnapshot maakt afzonderlijk gekopieerde uploads ook niet automatisch consistent. Documentatie over PostgreSQL SQL-dump.
Neem voor een WordPress-project de bestanden en de database op. Als URL's veranderen, volg de migratiespecifieke richtlijnen: een ongerichte zoek-en-vervang in de database kan geserialiseerde waarden beschadigen. Repeteer de gekozen methode op de kopie. WordPress-migratiehandleiding.
Leg een bekende enquiry en de bijlage vast, herstel ze en verifieer beide via de applicatie. Houd de originele back-up beschermd buiten de server die wordt verhuisd. Een voltooide bestandsoverdracht is geen acceptatie van het herstel.
Repeteer de workflows die de klant zal merken
Test met een toegangsbeveiligde tijdelijke hostnaam of een alleen-voor-operators naamtoewijzing. Configureer de applicatie voor die testroute, inclusief HTTPS en relevante callback-URL's. Voorkom dat de kopie productieberichten verzendt, echte betalingen verwerkt of productieschema's uitvoert. Gebruik goedgekeurde synthetische records in plaats van onnodige persoonsgegevens.
Schrijf vóór elke controle een verwacht resultaat op. Leg pass of fail, bewijslocatie en de persoon die het heeft beoordeeld vast; een screenshot van de homepage kan niet in de plaats komen van het hele raster.
Scroll horizontaal voor alle tabelkolommen.
| Workflow | Verwacht resultaat | Te bewaren bewijs |
|---|---|---|
| Formulier en bijlage | Eén opgeslagen enquiry en één leesbaar bestand; alleen testontvanger | Synthetische recordidentificatie en leveringswaarneming |
| Webhook | Goedgekeurde testevent bereikt de beoogde testconsumer | Eventidentificatie en resultaat van de consumer |
| Geplande export | Eén gecontroleerde run, juiste tijdzone, geen duplicaat van de oude server | Runidentificatie en vergelijking van geëxporteerde records |
| Redacteur- en bezoekersroutes | Verwachte rechten, redirects, assets en HTTPS-gedrag | Gecontroleerde URL's en eventuele foutdetails |
Definieer de laatste write op het oude systeem
Voor dit voorbeeld stelt het bureau een kort onderhoudsvenster voor: pauzeer het indienen en bewerken van enquiries, stop het oude exportschema, rond wachtend werk af of verantwoord het, en maak daarna de definitieve database- en uploadkopie. De klant moet goedkeuren hoe bezoekers wordt verteld dat inzendingen tijdelijk niet beschikbaar zijn.
Leg de laatst geaccepteerde enquiry-identificatie en het tijdstip waarop writes stopten vast. Valideer dat de bestemming dat record en de bijlage bevat voordat u nieuwe inzendingen toestaat. Houd de bron niet in staat onafhankelijke writes te accepteren terwijl DNS-antwoorden kunnen verschillen. Een project dat writes niet kan pauzeren vereist een applicatiespecifiek synchronisatieontwerp; improviseer er geen tijdens de cutover.
Houd een DNS-beslissingslog bij
TTL bepaalt hoelang DNS-antwoorden worden gecachet. Het verlagen bij cutover maakt al gecachete antwoorden onder de eerdere waarde niet ongeldig, dus bereid een TTL-wijziging vooraf voor en observeer de overgang vanaf relevante netwerken. Cloudflare merkt ook op dat lokale caching een zichtbare wijziging kan vertragen. Cloudflare DNS TTL-documentatie.
Log de recordnaam en het type, oude waarde, beoogde waarde, eerdere TTL, goedkeuring, wijzigingstijd en waargenomen resultaat. Controleer IPv6-records naast IPv4-records als beide bestaan. Behoud niet-gerelateerde mailrecords. Verifieer na de wijziging dat de publieke hostnaam de beoogde applicatie en de kritieke workflow bereikt, niet slechts het beoogde IP-adres.
Maak rollback een databeslissing
Spreek concrete stopcondities af: de laatste enquiry ontbreekt, bijlagen kunnen niet worden geopend, aanmelden mislukt, of een webhook bereikt de verkeerde ontvanger. Voordat nieuwe writes beginnen, kan een gerepeteerde terugkeer naar de behouden bron mogelijk zijn. Nadat de bestemming nieuwe enquiries accepteert, kan het herstellen van een oude back-up of het alleen terugdraaien van DNS die records verliezen.
Als na heropening een stopconditie optreedt, pauzeer writes, behoud beide kopieën en laat de genoemde operator de wijzigingen reconciliëren voordat het gezaghebbende systeem wordt gekozen. De klantgoedkeurder beslist of herstel wordt voortgezet of de afgesproken alternatieve route wordt gebruikt. Houd een kort incidentenlog bij in plaats van herhaaldelijk DNS te wisselen.
Sluit de verhuizing af met bewijs en eigenaarschap
Laat de klant het acceptatieraster beoordelen. Bevestig één actieve scheduler, het nieuwe back-uppad, eigenaarschap van alerts en het volgende observatiecontrolepunt. Behoud de bron voor de afgesproken periode en keur de buitengebruikstelling daarna expliciet goed. Verwijder tijdelijke toegang en testdata volgens de projectovereenkomst.
Gebruik het resultaat om de operationele verantwoordelijkheidslijst en projectbegrotingbij te werken. Deze procedure organiseert het werk van uw team; zij impliceert geen inbegrepen migratieassistentie of ononderbroken service.
Bronnen en review
Technische referenties zijn gecontroleerd op september 12, 2026. Voorbeelden zijn planningsoefeningen; de gedocumenteerde software-referenties bevestigen geen PrivateHostLab-servicecapaciteiten.