This page looks best with JavaScript enabled

Production to test migration strategy

 ·   ·  ☕ 3 min read

While we love to have production-like environments for user testing, managing data and the test environments can present unique challenges.

In today’s enterprises it is fairly common to have multiple test environments including staging, system / user testing environments and so on. These environments expect production-like features but only for specified users.

For example -

  1. Validations have to work as they are in production
  2. Document templates and document merge has to work
  3. Email and SMS communications have to work for select users
  4. Logins have to work for select users
  5. A few staging environments may need data in volume - what better data can you find outside of your own production environment?

As is the norm for typical enterprise applications, I tend to -

  • keep environments isolated
  • build environments on specific branches on demand
  • copy over whatever user configuration and user data that are relevant from production

While our build scripts make the build process really easy, the last item for data presents a problem.

For one, we may have sensitive data that has no place in test environments. This data is not meant to be played around by developers, testers and test users.

The second problem is to isolate our real customers from whatever plight awaits their data in test environments. For example, what happens in test environments should stay in test environment, and is not visible/have zero impact on anyone who is not associated with testing.

I try to work-around the problem of data and configuration management post-migration by (trying to) maintain and deploy a bunch of DB/server-side scripts to -

  1. Change sensitive fields like emails, and phone numbers
  2. Change encryption keys if required and dummify data in pre-identified fields like personal health information
  3. Scramble logins and passwords to something different

All this and more is done post data & configuration migration to target environments.

While all the setup activities need to be automated and be part of test migration scripts, I have never really gotten to the nirvana stage here.

Most of the times I end up doing some manual work and stitch together bit and pieces to -

  • migrate a part of a huge data-set with quirky data distribution requirements
  • migrate specific parts of production while merging that with parts from other environments

I can blame anyone and everyone for that, but at the end of the day, problem lies in my own improper budgeting. Having a lean team (or I alone) focused on a particular solution or project does not help. While the limited people, time and budget gets the work done really quickly and efficiently, there are essentials such as migrations that move to a ‘quasi-essentials’ bucket, and do not get the attention they deserve.

Stay in touch!
Share on

Prashanth Krishnamurthy
Prashanth Krishnamurthy
Technologist | Creator of Things