有一个快速的方法能够帮助你弄明白，迁移“随拎即走”和重构的工作负载到公有云上需要多长的时间。
我总是会被问到这样的问题：将一定数量的应用程序迁移到云端需要多久的时间？当然，这些咨询者会得到一个标准的答案：“这取决于具体情况。”
但是，你可以应用一些经验法则来大体了解一下，实施迁移的过程中你需要做多少工作。这些经验法则主要处理这些方面的问题：功能和目标点、复杂性、数据耦合以及云原生功能的使用。
许多企业期望不需要任何修改就迁移应用程序，也就是“随拎即走。”这意味着你不能利用云原生的功能，如身份管理、资产管理或治理，你想要牺牲云原生的功能来换取迁移的快速性。
如果你按照这个通常不是最佳的方法来迁移应用程序，那么为了转移代码和数据，你将需要两到三个开发者和DBA（数据库管理员）工作两到三天的时间。将天数乘以100，再减去在学习过程中的改进时间，你就可以在大约200天的时间里将100个工作负载迁移到公有云上。
然而，如果你决定重构或重建云原生应用程序，你的度量标准就不同了。你需要考虑有多少应用程序可能会被重构（按百分比计算），以及这样做的复杂性。
一般来说，需要重构的应用程序的百分比越高，迁移所花费的时间也就越多。我迁移百分之十的应用程序会花费一周的时间，因此，如果你重构30%将要迁移到一个公有云上的云原生应用程序，那么就需要3周的时间。将3周的时间乘以100，就是300周。
当然，如果你使用更多的资源来使迁移时间少于100天或300周（视情况而定），大多数这些工作就可以同时进行，只是需要你花费更多的金钱，承担更大的风险。
此外，不要忘记考虑许多其他一些事情，包括如何设计应用程序，数据库的耦合，数据库的类型……这个名单还很长。
这些问题都需要有一个答案，但是我们生活在这样一个世界中：人们想要拥有一个解决问题的“简要节录”。直到你获得一个准确的度量标准之前，经验法则能够提供这样一个解决问题的广义的“简要节录”。你只需要记住：成败在于细节。
