Skip to content

Populating Databases

There are multiple ways to populate a database, depending on your environment configuration, where your data resides, and application-specific requirements. Please notify the Game Warden team in advance if you require support for data seeding or migration.

Generally, you should either:

  • Include services in your application to handle seeding and migration, or
  • Provide scripts for the Game Warden team to execute on your behalf.

Data seeding vs. Data migration

Both processes involve managing data but serve different purposes:

  • Seeding: Populates the database with initial data so the application can run.
  • Migration: Transfers data from one environment or system to another, typically using a database dump.

Warning

In IL4+ environments, direct database access is not permitted.

Data seeding

Seeding provides an application with its first set of data. Examples include:

  • Creating an initial Admin user
  • Populating locations such as cities, states, and countries
  • Seeding demo or test data to verify app functionality

Seed data may be real or synthetic, depending on your needs. We recommend that you handle your own seeding. This gives you more flexibility to choose formats, tools, and timing.

Game Warden engineers can provide support if needed. For instance, you may send seed data to Game Warden, and our team can mount it as a Docker volume to ensure data persists across runs.

Data seeding support

If Game Warden handles your data seeding, this must occur before the Functional Assessment, as a populated database is required for testing.

You must provide:

  • Seed data
  • Seeding scripts or services
  • Clear execution instructions

Seeding process steps

The process for seeding data into Development (DEV), Staging (STG), or Production (PRD) environments depends on your existing standards, tooling, and whether your application exposes endpoints for data seeding.

  • If your application has endpoints enabled for seeding, you are encouraged to manage this process independently.
  • If endpoints are not available—or if data sensitivity requires tighter controls—the Game Warden team can assist. In that case, you must provide your seeding scripts and data files.

Game Warden will then issue AWS credentials via the Department of Defense Secure Access File Exchange (DoD SAFE). You will use these credentials to upload your seeding assets to an S3 bucket managed by Game Warden.

Data migration

Data migration involves moving data between systems or environments. This is common when transferring Controlled Unclassified Information (CUI) into Game Warden.

If your application and data sensitivity allow it, you can manage your own migrations. Otherwise, Game Warden will assist using your scripts and our credentials.

There are two primary methods for migrating data into Game Warden:

Submit a request—typically through the external platform’s ticketing system—to initiate the data transfer. Once approved, the Game Warden team will provide AWS credentials via the DoD SAFE . The external platform’s engineering team can then upload your data to a designated S3 bucket. Using the migration scripts or instructions you provide, the Game Warden team will handle the import into your Game Warden database.

You can request a migration through your customer Slack channel. In most cases, the Game Warden team will already be aware of this need and help coordinate a transfer time. We will provide AWS credentials via DoD SAFE so you can upload your data to a secure S3 bucket. Our team will then use your provided scripts or instructions to migrate the data into your Game Warden database.

If your application supports migration via API endpoints, you may also manage the migration yourself. However, ensure that the data is handled in accordance with all relevant sensitivity and compliance requirements.

Environment-specific considerations

Seeding and migrating data are environment-dependent processes. Although DEV typically requires seeding to get started, STG and PRD often involve data migration closer to go-live.

Your approach may vary depending on the Impact Level (IL), data sensitivity, and your goals. For example:

  • You might seed the same data across DEV, STG, and PRD.
  • In lower ILs such as IL2, you must use mock or synthetic data—CUI is not allowed.
  • In IL4+, seed or migrate data into STG first for validation before moving to PRD.

The Game Warden team commonly recommends dropping a data snapshot into STG for testing. If PRD testing succeeds, it’s complete; otherwise, we’ll help you revert and retry. Whenever possible, schedule migrations during low-traffic periods to minimize disruption.

Environment-specific considerations

  • DEV: Use mock/test data only — no CUI.
  • STG: Validate with production-like data.
  • PRD: Final deployment using mission data.

For IL4+ environments, always validate in STG before migrating to PRD.

Downtime

Migrations, especially from external platforms, typically involve some downtime. We strongly discourage migrating live data from an active application, as this risks data integrity.

We will work with your team to plan migrations during low-usage periods to reduce impact.

Best practices

  • Know exactly what data needs to be seeded or migrated.
  • Schedule activities to minimize disruption.
  • Use tools such as Flyway for automated data migrations or seedings.
  • Ensure scripts are tested and included when requesting Game Warden support.
  • Always verify data after migration is complete.