Populating Databases
Methods for seeding and migrating data into Game Warden environments, including environment-specific considerations and best practices.
You can populate a database in several ways, depending on your environment configuration, where your data resides, and your application requirements. Notify the Game Warden team in advance if you require support for data seeding or migration.
Use one of the following approaches to seed and migrate your database:
- 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.
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. Handle your own seeding whenever possible to maintain flexibility in choosing formats, tools, and timing.
Game Warden engineers can provide support if needed. For instance, you may send seed data to Game Warden, and the team can mount it as a Docker volume to ensure data persists across runs.
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 exposes seeding endpoints, manage the seeding process yourself whenever possible.
- 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 War Secure Access File Exchange (DOW 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, the Game Warden team can perform the migration using your scripts and Game Warden-provided AWS credentials.
You can migrate data into Game Warden using one of two primary methods:
Submit a request through the external platform's ticketing system to start the data transfer. Once approved, the Game Warden team will provide AWS credentials via the DOW 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.
Submit a request through the external platform's ticketing system to start the data transfer. Once approved, the Game Warden team will provide AWS credentials via the DOW 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.
Request a migration through your customer Slack channel. The team provides AWS credentials through DoD SAFE so you can upload your data to a secure Amazon S3 bucket. After the upload is complete, the team uses your scripts or migration instructions to import the data into your Game Warden database.
If your application supports migration via API endpoints, you may also manage the migration yourself. Handle data using all applicable 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 can 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 typically recommends restoring a data snapshot in STG for testing. If testing succeeds, the migration can proceed to PRD. If issues arise, the team can restore the previous state and retry the migration. Whenever possible, schedule migrations during low-traffic periods to reduce disruption.
- 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 from external platforms typically require downtime. Avoid migrating live data from an active application, as it can compromise data integrity. The Game Warden team coordinates migration windows with your team and recommends scheduling them during low-usage periods to reduce user impact.
Best practices
- Identify which data to seed and which to migrate.
- Schedule activities to reduce disruption.
- Use tools such as Flyway for automated data migrations or seedings.
- Test your scripts and include them when requesting Game Warden support.
- Always verify data after migration is complete.