这是不理想的，虽然某些对象从较新版本升级到较旧版本后可能会工作，而另一些则可能无法。
SAP通常不支持这种事情。

我认为 多年以来，大多数人都先升级沙盒，然后才进行prod/test和dev。

在某些情况下，我们也不得不这样做。 我们没有遇到任何问题。

官方的可支持性政策位于此KBA中：

https://launchpad.support.sap.com/#/notes/1574766

它可以工作-取决于版本之间的距离以及内容的复杂性，成功率可能会有所不同，但不能保证兼容性，并且SAP方面不支持。

如果不是您正在做的事情，则使用更高版本的环境（测试）来运行促销可能会与使用prod产生不同的结果。

获得版本，遇到麻烦的风险就更大。 如果您从BI4.2 SP06补丁4迁移到BI4.2 SP06补丁2，则风险很小。 从SP06到SP04，您可能会没事的。 如果要迁移的内容利用该版本中的某些新功能，肯定会遇到问题。

对于Univ Universe，BI4.2中的风险非常低，因为没有在其中添加任何新功能。

在过去的几次升级中，我的策略是建立一个临时沙箱环境以测试新版本。 我根据需要从实时dev/qa/生产环境中引入内容以进行测试，并要求开发人员在此处进行所有升级测试。 完成后，我将同时升级所有实时环境。 这样就消除了版本不兼容的风险。

关于您的特定问题：我认为这与版本不匹配无关。 迁移Universe或报表（但不能同时迁移）时，可以在CMS中打破两者之间的关系。 对于报表本身而言，这不是问题，因为报表仍然"知道"它引用的Universe，但是CMS中的元数据将过时。