This is similar to existing submitted idea #LUM-I-1028, but a little bigger. Here's contents of the support case I submitted on the matter:

need support in Teamraiser for event blueprint settings PER BLUEPRINT to be moved between environments.

Please describe the end goal or task you are trying to accomplish in the software and include replication steps.

Goal is to be able to identify a blueprint event in one envrionment , and export all of its settings such as:

a) Custom page content created in pagebuilder and related assets
b) Suggested messages and related assets
c) Autoresponder messages and related assets
d) Milestones

e)Participation Types

Then, go into an event blueprint in another environment (production) and import those settings. with all the assets included.

What problems have been encountered in attempting to accomplish this goal?

Right now we use Teamraiser blueprints for our 2 major fundraising events - Making Strides Against Breast Cancer and Relay For Life.

We have a QA environment (also called dev environment) and a production environment.

Given that our product also includes quite a bit of customization, when we introduce changes to either major event , they are tested in the QA environment, and then move up to production environment through regular change management procedures.

However, Teamraiser blueprints currently have several major areas as listed in goal that are not conducive to appropriate change management procedure. For all of those items, changes have to be introduced manually one change at a time in each environment separately.

The way our operational team handled that in the past is only creating all of those things in production. This then created a cascading chain of inefficiencies as follows:

a) Only being able to end to end integration test IN PRODUCTION prior to launching events. When issues occur that require adjustments at that point, essentially that starts a chain of bug fixes directly in production environment without any change management whatsoever, which is unacceptable for a PCI scope product.

b) Production environment necessarily getting out of synch with dev environment regularly due to production only changes, and therefore requiring twice a year backwards refreshes taking down development environments for 2(!!!) weeks at a time.

Instead, we want to do normal change management with event blueprints the same way we do with everything else, but creating them in the dev environment, and then, after all end to end testing is completed along with product customization integration tests, then blueprint being promoted up to prod as part of normal change management procedure.