Speaker 1: Hello, I am Jason Swan with dbServices, and today we are going to discuss upgrading to the non-profit cloud. Salesforce might eventually provide an upgrade feature to ease the process of translating your old org into the new non-profit cloud, but if you plan on doing the upgrade yourself, there are a couple aspects to consider. The most time-consuming part of upgrading to the non-profit cloud is going to be migrating your data from the old org to the new org, so here are a couple of general steps to ease the migration process. First, identify the metadata that you want to migrate to the new org. This includes objects, record types, fields, as well as any dependencies that these fields have to other objects and fields. After identifying the migration metadata, they have to be added to the new org so that the actual migration has something to map to. It is also a good idea to create an external ID for these objects in order to keep a relationship between the two orgs. Next, you will have to export the data from your old org. Salesforce's Data Loader application will be extremely useful, as it can be used to export and import data between orgs. Data Loader export records based on an SOQL query that the user defines, so either build a query beforehand or build one in Data Loader. After exporting your data, log into the new org with Data Loader, and then start importing. To import records, a user must select the object, the file to import, such as our export file, and then map the fields from the import file to the object fields. If there are any issues, Data Loader creates error logs to help users determine any issues with the import. After this, you will see your old records in the new org. These are the general steps to data migration, but this process gets complicated by the different models and objects in Nonprofit Cloud. The Nonprofit Cloud uses the person model for accounts. While other account models can have multiple contacts, the person account only has one contact and uses the fields on the contact and the account to represent an individual. The Nonprofit Success Pack prioritizes the household account model, so you will have to consider how to separate the contacts into their own person accounts. In order to maintain the relationships that contacts had in the old org, use the Party Role Relationship object. The Party Role Relationship object makes it easy to build connections for contacts and accounts. To make a Party Role Relationship, come up with a role name and a related role name, such as father to son, or parent company to subsidiary. Once made, the Party Role Relationship can be assigned between any number of contacts or accounts. Remember to consider what types of relationships your old org had before creating new Party Role Relationships in order to maintain the connections. The Program Management module in the Nonprofit Success Pack is still offered in the Nonprofit Cloud, but there are some differences that have to be accounted for when migrating data or using the module. The Program object is still the focus of Program Management, but some of the related objects have undergone some changes. The Service object that was used to show what services and benefits the program provides is now called the Benefits object, and the Program Engagement object that was used to enroll people into the program is now called the Program Enrollment object. Furthermore, the Service Schedule object is now the Benefit Schedule object, and the Service Session object is now the Benefit Session object. If you are mapping Program Management objects from Nonprofit Success Pack to Nonprofit Cloud, remember to migrate the old data to the newly named objects. Some old objects have been replaced with new objects entirely. The Service Delivery object has been replaced with the Benefit Assignment object, so consider what the old Service Delivery object has in common with the Benefit Assignment object when mapping fields in the migration. There is another new object in Nonprofit Cloud, the Benefit Type object, that does not have an equivalent object in Nonprofit Success Pack. The Benefit Type object is used to categorize the benefits that your program provides. Each benefit record requires a benefit type, so consider the types of benefits your organization provides and create those benefit types before migrating benefit objects. The Cohort object, which you might be familiar with in Nonprofit Success Pack, is not currently available in Nonprofit Cloud. It is currently on the roadmap, but creating a custom object to group Program Enrollments is an acceptable solution until Cohorts are released. The Case Management module offered in the Nonprofit Success Pack returns in the Nonprofit Cloud, but it has a different workflow. While both workflows start with the referral, Nonprofit Cloud uses the referral to build a case, which will be the focus for case management. Individuals, such as family members and coworkers, are then related to the case using the Case Participant object. From here, assessments and intakes are processed to better determine what care plans to assign. Care plans in Nonprofit Cloud are similar to case plans in the Nonprofit Success Pack, but there are still some differences to consider. Goals for individuals to work towards are still available, but the care plan also includes the Benefit Assignment object to show what benefits the individual is eligible to receive. Furthermore, the Client Notes object used to record interactions with the case individual have been replaced with the Interaction Summary object. The case individual may also be assigned to programs with the Program Enrollment object. If you are currently using the Nonprofit Success Pack, there are a couple of modules that you are probably familiar with that are not currently in the Nonprofit Cloud. One module is Volunteers for Salesforce. Volunteers for Salesforce enables easy management of volunteer programs by allowing users to track shifts, events, and participation, and assigning volunteers to shifts based on their skills. Another module is Address Management, which is great for maintaining address consistency between accounts and contacts. It also includes seasonal addresses for contacts that change addresses throughout the year, and address verification to ensure accuracy. There is no definite answer on if these two modules will be in the Nonprofit Cloud, so consider if the benefits that Nonprofit Cloud provides are worth the loss of these modules before upgrading. With that, we now have a good idea of the obstacles you may come across when upgrading to the Nonprofit Cloud. Thank you for watching. We hope we helped you understand the considerations you will need to make when upgrading. If you want to learn more, contact us at dbservices.com.