我们有一个基于Web的系统，它本质上是一个调查申请。到现在为止，我们一直在加载新的直接调查到数据库（如迁徙路线迁移）。这显然是站不住脚的长期的，我们需要把创建新的调查到管理用户的手中的权力。其中一个方面是增加了UI，这样管理员用户可以创建新的调查。
但是，我们希望管理员用户创建和第一让它在宽松的生产环境之前测试在测试环境中的任何新的调查。由于这些调查是复杂的，有一个真正的危险，即调查是在测试环境设置是从别人怎么做在生产环境中的设置稍有不同。我的目标是消除这种风险。
我的问题是关于技术机制（S），我们可以实现，这样管理员用户，在自助服务的基础上，“迁移”从他们的测试环境（在那里，他们已经做了所有他们的测试和验证的）调查的生产环境 - 例如，我们有很高的信心，迁移调查（S）将设置相同。像Moodle的应用已经有这种功能，内置的。
我认为：
在这个阶段，我倾向于JSON的方法，反而会渴望听到任何其他的想法或库，我们可以很容易地集成到Spring的引导程序，这将有助于这一进程。
说实话，通过引入独立的情况下，解决了这类问题听起来像一个可怕的想法：不仅迁移部分是棘手的。你必须确保在任何时候都兼容。想象一下，一个管理员使用了过时的版本，或者没有配置正确了实例（每个管理员的梦想）。即使迁移本身不产生错误的结果可能是在年底不同（这就是你真正想要什么，以避免）。
据我所知，你现在看一个调查的大部分原始信息，不知怎的，出现在你的数据库中，然后被应用程序所显示。从这个角度来看，你显然不能告诉一个测试测量及生产调查之间的区别。
这就是为什么你真的应该扩展你的模型！
这里不仅仅是一个调查更多。有一个调查草案和/或调查预览区域，有调查创建过程用户经历，从一个选秀生产调查的旋转等处理
如果添加这些概念到应用程序的使用情况像你描述的应该是很容易实现的一个（你已经提到的有计划的用户界面，对吧？）。
希望我可以帮助你。对不起，我知道这并不完全回答你的问题。