In many instances, the data to be migrated in Salesforce is simple enough that it can be imported with a tool like Jitterbit or the Salesforce Data Import Wizard.
There are some situations though, when the migration might be difficult or cumbersome to implement with one of these tools. It’s likely that in these cases developing an application will be more cost-effective than the standard approach.
Here are a few cases when a Salesforce developer should create an application to process the data import by using Visualforce and Apex:
– the migration needs to be repeated several times. An admin might need to import data periodically into Salesforce, or an organization might want to import their data into multiple Salesforce instances.
– the data contained in an input file will result in multiple levels of related Salesforce objects like accounts, contacts, and addresses.
– the transformations necessary are complex and difficult to implement in a query
How to do it:
– create a Visualforce page that will be the application interface.
– add apex:inputFile controls to the page to upload the files in memory
– create a controller containing the methods to parse and process the file imports
It all sounds pretty straightforward, but here are some obstacles the developer might run into:
– the maximum file size that can be uploaded is 10 MB. If your file exceeds the limit, you might have to manually split prior to processing.
– you might hit various governor limits while processing large files.
One way to resolve this issue is to programmatically break the files in batches, and invoke future methods for each batch. You need to adjust the batch size so you won’t exceed the 50 future job limit.
Here is the Visualforce page:
and the Apex code for batch processing accounts with a future method:
by Vladimir Martinov
We have a project where we will be migrating data from 1 common data source into 9 Salesforce instances. The process defined here and implemented by Vladimir for our situation saved us many hours of work. Definitely an approach we would use again.
Comments are closed.