Test and Rollout upgraded interfaces

It is best to see how new code works before committing to any major change. Fortunately this is easy with Iguana, and follows established best practices of parallel running for testing and the initial release cut-over period.

Burn in Test

Once you have interfaces redirected through Iguana it’s not at all a bad idea to let things ‘burn in’ for a while before releasing the new code to production. The concern here that there may be things that the legacy technology was doing that you are not aware of.

Giving things a couple of weeks to run in production with this redirected data flow is a good way to manage the risk associated with making this change. It gives you the opportunity to verify that there are no unexpected side effects or problems before diving in to the next part of your project.

Have the data flowing through an engine like Iguana gives you the opportunity to observe more closely how it actually works and give you much greater comfort level for the next stage of recreating that logic within Iguana.

Parallel Running

Also you can always run the old and the new Lua based logic in parallel for a few weeks. You can compare transformations on the fly with the old code so that it notifies you or logs a warning when differences occur – i.e. edge cases that you might not have anticipated.

You can set up alerts to tell you when things don’t match.

Once again this reduces the risk of performing this kind of heart surgery on your infra-structure.