我相信可以通过Salesforce元数据API来做到这一点，但是我还没有亲自使用过该API.我曾经有人向我推荐它，作为处理类似任务的一种手段.

I believe that it might be possible to do this via the Salesforce metadata API, but I haven't personally used that API yet. I've had people recommend it to me as a means for handling similar tasks.

我会这么怀疑迁移的好处.除非要创建的对象和字段太多，否则创建对象和字段的简单任务将花费大量时间，这有什么好处?请记住，您可以获取和设置Salesforce标准对象和自定义对象上的字段，而无需编写与这些对象对应的代码(至少可以在Apex中使用).同样，每个对象自动获得一个标准控制器来处理显示和标准操作.

I'd question the benefits of doing a migration so generically. Unless you have so many objects and fields to create that the simple task of object and field creation will take significant time, what's the advantage? Remember, you can get and set fields on Salesforce standard and custom objects without writing code to go with those objects (at least you can in Apex). Likewise, each object automatically gets a standard controller to handle display and standard operations.

您应该问自己，您的数据和数据模型是否足够干净以生成代码.你确定吗?真的很确定吗?为了解决报告问题，早在2005年就将小部件计数字段添加到了装运对象中，该怎么办?没有人使用它了.还是要在您的新数据库中使用它吗?

You should ask yourself if your data and data model are clean enough to generate code from. Are you sure? Really really sure? What about that widget count field that got added to the shipment object back in 2005 to solve a reporting issue? Nobody uses it anymore. Still want it in your new db?

两次将Notes数据库迁移到Salesforce，两次导出到CSV以及其他人都已加载数据.第一次导出只是联系人和客户的简单导出.我第二次编写自己的Lotusscript导出器，因为在执行Salesforce导入之前需要解决某些数据问题.第二次使用数据加载器完成加载.如果我自己加载数据，则使用需求工具.它是更具工业实力的工具.重复数据删除功能本身可以节省您编写大量自定义代码的时间.

Both times I've migrated Notes databases to Salesforce, I've exported to CSV and someone else has loaded the data. The first export was just a simple export of contacts and accounts. The second time I wrote my own Lotusscript exporter since I needed to fix certain data problems before doing the Salesforce import. The second time the load was done with the data loader. If I was loading the data myself, I'd use Demand Tools. It's much more industrial-strength tool. The de-duplication features alone can save you writing a lot of custom code.