As part of a migration from Siebel to Salesforce, we need to migrate activities. Can you help me complete a list of items we need to take into consideration ? Also, please do add more details to any point. Other than Activities, we have Accounts, Contacts & Campaigns to migrate, but this question is specific to Activities

Here's my (short) list:

  1. Identify criteria for mapping records to event or task
  2. Map activity fields (including owner)
  3. Stage data load based on date ranges - business wants ALL data moved
  4. ....

Its more on (3) that I need help. I understand that SFDC archives Activities, so the old data we upload is going to get archived eventually. The API says the IsArchived is not updatable [2,3] - (or am I reading it wrong) so I can't insert them as archived? Any other special considerations I need to do here?

Thanks !

1 Answer 1


Migrating activities is fairly trivial in most cases, since there are usually very few fields to work with.

Mapping Task/Event

Tasks have a status (done/not done), while events have a starting date/time and duration (or ending date/time). You should be able to identify most records from any reasonably designed system based on one of these two pieces of data being present. In the absence of both, other clues may exist, such as an activity type of "Email" (task) or a "Location" (event).

Most activities describe "who" they are associated with. This will be a lead or contact in salesforce.com. This may be laid out in the source from two separate tables, or a table of people with a certain "type" (usually named "lead" or "contact").

Many activities also describe "what" they are associated with. This is probably the most painful part of data mapping, because it could be any of a number of items, though the most usual cases are "account", "opportunity", and "case" (trouble ticket, etc), although custom objects may be possible.

Neither a "who" or a "what" preclude an activity being a task or event, although events usually include multiple "who" references, while tasks usually do not. The determining factor is almost exclusively a "status" value, or a "date/time" and "duration" value.

Mapping Relationships

Most systems use either unique IDs, or names, to reference related tables. Hopefully, it's a unique ID, which makes importing trivial. You should be able to use VLOOKUP (Excel) or queries (e.g. most database-driven systems) to attach a salesforce.com ID to an activity. Generally, you'll want three relationship pieces of information: the owner, the "who", and the "what." You can also map "Created" and "Last Modified" fields if you enable support for this feature by submitting a case to salesforce.com.

Special Considerations

Date and date/time values are in GMT in salesforce.com. You may need to convert your times from the other system's local time zone to GMT in order to upload the activities successfully. Also, dates must be in YYYY-MM-DD format, and date/time values must be in YYYY-MM-DDThh:mm:ss.SSSZ format, where T and Z are literal values, SSS is milliseconds (000 is fine), and hh is 00 through 23 (in Java's Date format parlance, "kk"). The data loader accepts several formats depending on locale, but this date and date/time format is considered the safest.

Archiving is automatic, periodic, and inevitable. You can't specify archived records, because they'll be automatically archived by the system when they meet certain criteria. Archiving doesn't reduce the activity's storage usage, but simply excludes these activities from reports and list views. The only special consideration is that there is no need to consider this behavior, because the system manages this flag for you. You can request a "further" archive period than what the defaults are, but this will significantly impact reporting speed for activities, so advise caution against expanding the window.

Created and Last Modified audit fields don't normally allow themselves to be inserted or updated. You can enable the feature to insert these values if they are important to the organization. You can only insert these values, not update, so if the data isn't mapped initially or is incorrect, the records should to be deleted before they are re-inserted.

You can load as many records as you want, assuming you don't run out of storage space or API calls for the day. See Setup > Company Profile > Company Information in regards to the number of API calls you get per day. Every 200 records in a batch is one API call. Each activity uses 2KB of database storage, regardless of content. You can find the current usage and maximum capacity under Setup > Data Management > Storage Usage. Advise that they load only relevant records, such as the last three years or so. Large, continuous imports may affect other integrations that also need API access until the 24 hour rolling window passes.

Loading activities requires that the related information (contacts, leads, accounts, opportunities, cases, etc) all exist first. You may need to load or map a ton of supplemental data in order to load these activities. In general, each additional table of data will require a minimum of an hour of mapping in most cases, assuming a proficiency in Excel. Of course, really small tables might only take a few minutes, while really large tables could take considerably longer.

Also, there may be some pre-configuration required before loading the data. For example, status values in salesforce.com should match incoming values. Data might need to be trimmed to fit inside the space provided (e.g. an event with 60,000 characters of description will lose half its text). You should try to identify these potential problems beforehand; a quick query will usually suffice if you load this data into a database like Access or MySQL.

Assuming there are no import errors, you can just spot-check the data when the import is done. If a few records look correct, then generally all the data will be correct; any errors would have been reporting during the import process. Conversely, if a few records are incorrect, most likely all records are incorrect. This usually comes in the flavor of a mis-matched lookup or incorrect translation of date or date/time values. This knowledge saves considerable time post-import.

You should try a trial import of 10-15 records before running the entire load. If the trial goes well, the entire import should go well. Retain the error files from the loads so that you can fix the problems specified, instead of having to wipe out all the data and starting clean.

Some fields are always read-only, most notably the auto-number data type. You can change the type to "text", import the data, then change them back to auto-number when you're done, if you need to.

Consider locking out all users except the user performing the import for the duration. You wouldn't want someone causing row locks or trying to synchronize their mobile device or Outlook while you're loading the data. While small imports are okay to leave the system open, the chances of Something Bad™ happening increase with the number of active users. While the system is multi-tenant, synchronization is generally best avoided during the middle of data loads, to be safe.

Perform large loads overnight or on the weekends. The system load is lower, so your performance will greatly increase, perhaps 50-100% or more. Also consider disabling validation rules, workflow rules, and triggers to boost your speed even more. Apply business logic to the records before importing to simulate the effects of the validation rules, workflow rules, and triggers. Perform the data load as a system administrator to avoid checks on sharing rules, etc, and you'll gain another significant boost to speed.

When loading in records, consider ordering them in reverse chronological order, with the newest records first. This gives immediate access to the most relevant information sooner, and then you can stagger in older records as you proceed. If you plan on splitting by date ranges, you should probably not choose arbitrary or calendar-spaced dates, but rather based on record counts, such as loading 20,000 records at a time each day. This will help manage API usage.

  • Wow! Here's a quick summary from this answer: 1. Related records should exist first 2. Set date/time values in GMT, YYYY-MM-DDThh:mm:ss.SSSZ format 3. Archiving takes care of itself 4. Consider inserting values for audit fields 5. Time & space considerations, perform during off-peak times 6. Load newer, more relevant data first 7. Map fields and types/lengths 8. Perform sample loads of 10-20 records 9. Split data loads based on volume instead of date range
    – LVS
    Sep 6, 2013 at 3:44

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .