Here’s How to Migrate Data to Content In Salesforce

Altvia’s advanced platform solution built on top of Salesforce utilizes’s Account/Company and Contact features. Altvia takes the functionality further with proprietary integrations and interactions to migrate data. This includes connections with products like email marketing, an LP portal, and our data visualization tool. 

The result is a solution that enables firms to raise and deploy capital effectively, maintain compliance, and deliver a secure, reliable, and transparent experience to stakeholders and investors.  

First, however, you have to migrate data into the system. 

In order to make that process easier, our team of experts compiled their knowledge of Salesforce (SF) into clear, concise instructions.  

Use this guide to migrate data, including documents and attachments, to the Content section of and you can be operational and productive in no time.

Note: there is a per-day limit of 5,000 files for Content submissions as you migrate data.

Covert the org to use content

  • Enable Content and add all users as Content users.
  • Replace Attachments-related lists throughout the system and add related lists for Content (done by adding a lookup to the objects as custom fields on Content-Type layouts).
  • No new attachments can be added during the migration. You might have to do this after-hours to limit disruption.

Exports you will need to Migrate data

Attachments & Document Files: Start by doing a full Export including all files from within SF. This will get you all the attachments, documents, etc. named by their record ID in SF.

  • Setup->Data Management->Data Export->Export Now.
  • Be sure to check “Include in Export” at top and “Include all Data” at bottom.
  • Note: If an export has been done in the last 48 hours, you will not have the option to “Export Now”. You will have to wait.
  • The Export will complete in 5 minutes to 2 hours depending on its size and SF system availability, and an email will be sent to the app-xprod email address. Alternatively, you can periodically refresh the page.
  • One or more .zip files should be on the Data Export screen after it has completed.
  • Download all of them…they will only be available for 48 hours.
  • Place the .zip files somewhere on your local machine.
  • Extract all of them within a folder:

  1. Will result in multiple .csv files of the data. These can be deleted or filed elsewhere.
  2. Will result in an Attachments folder with all attachments. You will need these. Make sure they are all in the same folder.
  3. Will result in a Documents folder with all documents. If migrating these, you will also need these.

Attachments Data.csv: Export all current attachments in Data Loader. Exclude the column “Body” from the export.

  • Keep the original Attachments export .csv in a safe place. You’ll probably need to refer to it.
  • Verify the number of Attachments in this export matches the number you have in the Attachments folder from the Export. Ditto if you are also migrating Documents. 

ContentVersion.csv: Export the current CONTENT (Content Version) table in Data Loader. Exclude the column “VERSIONDATA” from the Export.

  • Keep the original file as you’ll probably need it later. 

Build your import file

Build your Content Version .csv by first exporting a test record from the Content Version table in data loader. Exclude the “VERSIONDATA” column from the export. Include the following columns or delete the rest after export.

  • ID: Unique ID of Current version of Document that is displayed when you click on a document. Will be blank in the import file.
  • CONTENTDOCUMENTID: Unique ID of a Content Document. Different than above. Will be blank in the import file.
  • TITLE: This is what the document will be called. Title of the document from the Attachments table or other sources.
  • VERSIONDATA: Full file path to the document being inserted without file type extension (i.e. C:ClientsAttachments0PA000002gpI3Mai). See Helpful Hints below. Must be populated and without file extension.
  • PATHONCLIENT: Full file path to the document being inserted with file type extension (i.e. C:ClientsAttachments0PA000002gpI3Mai.pdf). This tells Content what the file type is so that the document can be previewed in SF. If the extension is not assigned correctly, the import is pretty much worthless. See Helpful Hints below; Must be populated and with the file extension.
  • OWNERID: In the case of attachments related to other records, this is the owner id (18 char) of the other record, not the attachment (depending on how attachments were loaded, you may be able to simply take the owner of the attachment). This is because some attachments have the owner as the Admin if they were loaded via an API call. You want the actual Owner, as any security in the org is driven off of that (Requires additional vLookup to the export of the related records tables); must be populated.
  • FIRSTPUBLISHLOCATIONID: This is the workspace ID (18 char) that you are inserting each document into. Must be populated.
  • RECORDTYPEID: This is the ContentType ID (18 char) of the Content-type you want to assign to this document. Must be populated if more than one Content-Type defined in the org. Otherwise, it defaults to General and you don’t need the column.
  • ALL APPROPRIATE LOOKUPS to other objects (i.e. Contact__C, Account__C). Optional.
  • ALL APPROPRIATE FILTERS (i.e. Document_Type__C, Year__C. Needs to be populated manually if you want to filter information. Optional.
  • ALL APPROPRIATE LEGACY IDS: We like to add the id of the document from where it came from (may be internal or external IDs). Optional, but highly recommended.

Helpful hints before you migrate data

  • Build your VERSION DATA: Add the static path in one cell in your .csv (i.e. G2 has “C:ClientsAttachments” in it). Add the appropriate attachment ID for this document (i.e. H2 has “00PA000002gpI3Mai” in it). Build the file path by using concatenate function below; G2&H2. Should result in C:ClientsAttachments0PA000002gpI3Mai.
  • Determine File Type: Use formula below to extract the characters after the period at the end of the title of the document to grab the file extension. A2 is the cell reference containing the Title of the document that has an extension (i.e. Sample.pdf); =RIGHT(A2,LEN(A2)-FIND(“^^”,SUBSTITUTE(A2,”.”,”^^”,LEN(A2)-LEN(SUBSTITUTE(A2,”.”,””))))); Result should be “pdf”. Eyeball all the results for sort by the results as many times you get “.pd” or “.xl”. Fix the title of these documents so you get a legit file extension.
  • Build your PATHONCLIENT: Concatenate the contents of VERSIONDATA that you already built (C:ClientsAttachments0PA000002gpI3Mai) with the result of the file type you have determined (i.e. “.pdf”). Use concatenate function to give you the following result (i.e. =G2&”.”&H2…note the addition of period in quotes); C:ClientsAttachments0PA000002gpI3Mai.pdf.
  • Data Loader 21.0 does not report on “File not Found” Errors. It gives you no error or success file record for this situation. Suggest using Data Loader 20.0 for loading of Content Version table.
  • CSV’s are finicky. You cannot have more than 1 worksheet in a given .csv. Well, you can, but when you save, it will delete all but the first.
  • VLOOKUP: Excellent function. You will need to use it.
  • FIXID: If you happen to have 15 char ids, you can use Excel function =FIXID(A2) where A2 contains the 15 char id.

Following the instructions above will help you migrate data more efficiently and give you positive forward momentum in implementation and product adoption.

For more tips and tricks on how to migrate data and how to manage data in general, visit the Altvia Community.

A traditional crm was built for general ‘customer’ scenarios

Software platforms have made the world a better place by making work a better place. Indeed the world is better off when people enjoy their jobs even marginally more, and workplace applications on big CRM platforms like have done that and much more.

But the potential that platforms like these offer presents diminishing returns: once the platform provider has engineered too many industry specific components into its platform, its usefulness for other industries begins to be threatened, and with that so do the usefulness of the component tools built into the platform.

So it is with the CRM category that has defined: it is generic enough to work for many industries, and yet still offers the potential for others to round off the edges and nail more vertically-oriented and extremely tailored software solutions.

Private capital markets are actually a great demonstration of this dynamic. Where generic CRM platforms simplify — appropriately so — to assume there’s a business, a customer, a sale, and service of that customer, there are a few industry-specific pieces that are missing.

Take for example, that investors become customers by investing through legal entities the GP raises. It’s a subtle but important nuance that just doesn’t make sense at a platform-as-a-service level (because it’s overly complicated for a simple one-time sale that many industries require), but which can easily be added without 10 years or software engineering. Once provided, the rest of the platform’s components become tremendously powerful again and you’re set to take over the world.

As a traditional CRM in our pillars methodology, these nuances must be present to properly account for investors in these legal entities, potential target companies and which are owned by these entities, the context of all interactions with these parties (as well as the appropriate overlap, ie co-investments), and how you’re arriving at finding these opportunities on both sides of the equation, such that you’re able to piece together what’s effective and what’s not. Not just because we say so, but because these are the very relationships and data that are key to the motivation behind a CRM in any industry.

It’s critical, too, that the valuable publicly-available information that helps to enrich CRM systems and save users painful steps of entering it themselves is fully-integrated at the platform level.

Again, look no further than the 3,000+ pre-built integrations that — the creator of the CRM platform concept — has at a platform level to do so, and which only exists by way of holding just short of overly-specifying certain industry workflows that would present challenges to properly integrate.

Stakeholder reporting and communication (investor relations) draws on a range of datasets

The traditional “customer service” model of CRM systems once again makes overly-simplified assumptions about the customer relationship when applied to private capital markets.

In fifteen years I personally have yet to hear the terms “warranty” or “service call” in this market because it’s just not the same. But make no mistake, as uncomfortable as it may be to say aloud, customer service is more important now than ever and it’s constantly happening; the industry is, after all, considered to be a financial “service”.

As it turns out, that service is primarily information-based — it’s driven by data and takes the form of reports and analysis that drive decisions, and then end up again in investor-facing reports and analysis.

The foundational elements of a private capital markets CRM must be built such that they accommodate this data (like we discussed above), but so too that it can accommodate additional supporting data that investors (customers!) need in the context of service.

Oftentimes this supporting data — financial metrics and time-based values, for example — is believed not to meet the traditional definition of CRM and the natural thought is “well, better do this in Excel!”.

While I happen to believe Excel is still the greatest software application ever built, its introduction to this value chain we’ve discussed herein actually creates the problem many firms suffer from: key data needed to provide customer service (again: effectively the entirety of a firm’s reports and analysis) is now in disparate systems and detached.

Both of those dynamics are important and distinct: not only is this supplemental data disparate, but when brought together there is no logical association that can be made between the two data sets.

Allow me, then, to make the point very simply: not only can this financial and time-based value data (you may be thinking about is as “portfolio monitoring” or “accounting”) be a part of a CRM, it is arguably the most important part of a CRM because it’s at the core of what providing service to the customer entails — information that comes out of data!

Firms need a digital method to engage stakeholders (ie investor portals)

Investor portals are not new; in fact, for many of us — including myself — they conjure up horrifying nightmares in which we’re aimlessly guessing at folders to find the newest document we need.

So in lies the opportunity: not only have the portals we’ve come to hate not simplified the process of acquiring information, they’ve failed to create an entirely new experience that is “customer service” driven.

To be fair, this is not a B2C market where you’d be long out of business for not having focused on customer service and thus the customer’s technology-driven experience. But don’t expect to be around too much longer if you aren’t thinking about this shift.

Today’s institutional investors increasingly expect this same consumer-like experience, and a massive opportunity is being missed by not providing it. It’s not about providing them the experience they desire; it’s more about the ability to measure engagement that is had in return.

Put simply: what’s keeping the market from providing this experience is the availability of the information that’s required to create the service that provides the experience.

If you’ve hung in this long, you know that by focusing on your CRM, you have the data that’s required to manage the customer relationship and the technology-driven experience through which that information is shared to create a differentiated and opportunistic customer experience.

migrate data