Services

Database migration workflow

Database migration workflow

Assistance helps teams standardize CI/CD, release readiness, GitOps promotion, environment management, and emergency delivery support. This page explains the user-facing operating model for database migration workflow: what Assistance can operate, what the customer owns, and how onboarding, support, changes, and escalation work.

When to use this#

Use this when data, workloads, environments, or accounts are moving between providers, regions, teams, or operating models.

Good fits include:

  • teams that need a documented operating boundary before production changes;
  • retained DevOps, SRE, DevSecOps, or platform support where day-2 ownership must be explicit;
  • audit, release, migration, or incident work where decisions and evidence need to be traceable.

This is not a generic vendor manual. Vendor-specific commands belong in the customer runbook only when they are part of the agreed workflow.

What Assistance operates#

Within the agreed engagement boundary, Assistance can operate or support:

  • discovery, migration plan, rehearsal, cutover checklist, rollback path, validation evidence, and stabilization support;
  • onboarding checklists, implementation plans, and production-readiness reviews;
  • monitoring signals, alert routing, runbook updates, and incident triage;
  • planned change requests, maintenance-window preparation, and rollback notes;
  • handoff documentation so customer teams understand how to request help and approve changes.

What the customer owns#

The customer remains responsible for:

  • business priorities, launch timing, acceptance criteria, and internal approvals;
  • cloud, SaaS, identity, repository, and billing accounts unless a different ownership model is contracted;
  • application code, data classification, user access approvals, and product communications;
  • legal, regulatory, procurement, and risk decisions based on Assistance-provided evidence.

Engagement models#

ModelBest forTypical Assistance role
Assessment or auditTeams that need a short, evidence-backed planReview current state, identify risks, and provide prioritized recommendations
Implementation projectTeams making a defined platform, delivery, security, or docs changeDesign, build, migrate, validate, and hand over the workflow
Retained operationsTeams that need ongoing DevOps, SRE, DevSecOps, or platform supportOperate agreed components, manage changes, and drive continuous improvement
Emergency responseTeams facing an outage, blocked release, security event, or urgent migrationStabilize, coordinate escalation, document recovery, and produce follow-up actions

Onboarding workflow#

  1. Intake — confirm systems, owners, environments, repositories, providers, risk level, and success criteria.
  2. Assessment — review current runbooks, access, alerts, deployment flow, security controls, and known incidents.
  3. Operating boundary — agree what Assistance operates, what the customer owns, support hours, severity definitions, and approval paths.
  4. Implementation — apply the agreed changes with reviewable pull requests, change records, and rollback plans.
  5. Go-live or handoff — validate the workflow, publish runbooks, confirm escalation contacts, and schedule the first review.
  6. Operate and improve — use incidents, failed changes, support tickets, and audits to maintain an improvement backlog.

Support and change requests#

Route requests through the agreed support channel with environment, affected service, business impact, urgency, recent changes, and relevant logs or screenshots.

Request typeExamplesExpected workflow
Standard changeconfiguration update, runner label, access review, docs updateTriage, scope, approve, schedule, implement, and record outcome
Urgent changeblocked release, failing production pipeline, capacity exhaustionClassify severity, stabilize, communicate cadence, implement safest recovery path
Advisory requestarchitecture question, compliance evidence, migration optionClarify decision, provide recommendation, document assumptions and trade-offs
Incidentoutage, suspected compromise, severe data or delivery impactOpen incident channel, assign roles, preserve evidence, recover service, publish follow-up notes

Not included by default#

Assistance does not guarantee zero downtime without a tested architecture, rehearsal evidence, and an agreed rollback plan.

Any stronger SLA, regulated compliance claim, 24/7 coverage, legal responsibility, or provider-account ownership must be written into the statement of work or support agreement.

Getting started#

Open a support or onboarding request with the service area, current environment, desired outcome, deadline, and known risks. Assistance will confirm the operating boundary before making production-impacting changes.