Contenu connexe Similaire à Salesforce.com Org Migration Overview (20) Salesforce.com Org Migration Overview2. Agenda
• Single Org Benefits, Opportunity & Challenges
• Project Team
• Systems Review
• Process & Access Review
• Data Considerations
• Migration Strategy
• Migration Tools
• Next Steps
• Appendixes
2
| Copyright © ShellBlack.com
3. A Single Org Enables…..
• Greater Management Visibility
§ One place for all roll-up/drill-down reporting
• Collaboration
§ Maximize the corporate rolodex: Increase Upsell & Cross-Sell Productivity
• Standardization of Processes
§ Case Management, Opportunity Management, Customer Lifecycle
• Global Standardization & Economies of Scale
§ Consistent experience with User Education, consolidated Change
Management, single point for integration, data cleansing and
internationalization
| Copyright © ShellBlack.com
4. Single Org Model HQ
BU1
BU2
BU
3..
§ Cross
business
unit
collabora1on
§ Salesforce
Cha5er
§ Shared
solu1ons
for
common
business
processes
§ One
set
of
configura1on
and
code
to
address
common
business
requirements
§ Reuse
decreases
development
costs
Benefits
§ Ability
to
share
data
where
appropriate
§ Alleviates
need
for
data
silos
§ No
complex
data
integra1on
solu1ons
§ Unified
repor1ng
§ Single
login
to
access
mul1ple
business
func1ons
§ Org
complexity
could
become
a
barrier
to
progress
§ Poten1al
to
hit
specific
Org
limits,
such
as
number
of
custom
tabs,
objects
and
code
lines
§ Org-‐wide
seIngs
(e.g.
security
and
sharing)
could
become
difficult
to
govern
and
manage
Risks
§ Run
1me
processing
could
be
impacted
by
volume
of
code
deployed
resul1ng
in
breaches
of
API
and
APEX
governor
limits
§ Time
to
market
and
innovate
could
be
impacted
by
number
of
teams
rolling
out
new
func1onality
§ More
teams
upda1ng
shared
configura1on
and
code
means
more
regression
tes1ng
is
needed
as
complexity
increases
over
1me
§ Fewer
sandbox
environments
reduces
tes1ng
capabili1es
| Copyright © ShellBlack.com
5. Opportunities and Challenges
• Throughout the project opportunities will present
themselves to potentially streamline and improve
business processes
• The challenge will be to capitalize on these
opportunities wherever possible without putting the
migration timeline at risk
• Business owners of both orgs will be faced with
compromises for the greater good
5
| Copyright © ShellBlack.com
6. Agenda
• Single Org Benefits, Opportunity & Challenges
• Project Team
• Systems Review
• Process & Access Review
• Data Considerations
• Migration Strategy
• Migration Tools
• Next Steps
• Appendixes
6
| Copyright © ShellBlack.com
7. Org Merge Project Team Roles
• Sponsor
§ Provides support
§ Assist with change management / communication to the rest of the
organization
• Salesforce SMEs
§ Making configuration changes / moving data
§ Admins / consultants
• Stakeholders / Business Process SMEs
§ Knows the business and understands the data
§ Knows why things are configured the way they are
§ Empowered to represent functional areas / departments
§ Can make decisions on what is critical information (replicate) and what is not
(jettison)
§ Familiar enough with the data to validate the data loads
• Project Management / Consulting
§ Creation of the Project Plan, assignment and reporting of tasks and progress
§ Facilitating discussions around process & best practices (drives towards
consensus)
7
| Copyright © ShellBlack.com
8. Project Team Skills and Capacity
• In order to create a Project Plan with task
assignments, need to determine for SourceHOV’s
internal team:
§ Skill Set / Experience (i.e. Configuration & Data Loader)
§ Hours per week each person can work on the migration
– Admins
– Functional SMEs
Determine the task workload that can be handled internally to
know how many external resources to pull onto the project
8
| Copyright © ShellBlack.com
9. Agenda
• Single Org Benefits, Opportunity & Challenges
• Project Team
• Systems Review
• Process & Access Review
• Data Considerations
• Migration Strategy
• Migration Tools
• Next Steps
• Appendixes
9
| Copyright © ShellBlack.com
10. Systems Review
• The first step to planning an org migration is to identify all:
§ Similarities, Differences (gaps), and obsolete (unused) components
• Review processes enabled by the systems, and map the desired future state
• Review configuration of both systems, including:
§ Tabs used (including Custom Tabs and Renamed Tabs)
§ Custom Fields, Custom Links, Triggers, and Custom Buttons
§ Custom Objects and relationships
§ Pick List values
§ Formula fields, Data (field) Validation Rules
§ Email templates, mail merge templates
§ Rules (Assignment, Escalation, Workflow, Approvals, Field Updates)
§ Profiles, Page Layouts, Search Layout
§ Sharing Model à Role Hierarchy, Public Groups, Account Teams, and Sharing
Rules
§ Forecasting à Hierarchy, quotas, etc.
§ Extended applications à Partner and Customer Portal, Sites
§ External integration points à Web to Lead, Web to Case, Email to Case, API
version, APEX code
§ Data model impacting features à Person Accounts, Territory Management
§ Multi currency or multi language?
• See the Appendix for a more comprehensive list of review items
| Copyright © ShellBlack.com
11. Systems Review
• Track your limits by object (Setup > Object Name > Limits)
and org-wide (Setup > Systems Overview)
Note: Screenshot is from an
“Unlimited” org
11
| Copyright © ShellBlack.com
12. Agenda
• Single Org Benefits, Opportunity & Challenges
• Project Team
• Systems Review
• Process & Access Review
• Data Considerations
• Migration Strategy
• Migration Tools
• Next Steps
• Appendixes
12
| Copyright © ShellBlack.com
13. Process & Access Review
• The next big phase in planning an org migration is to
review your business processes and information access
• Involve individuals (SMEs) that represent each system(s)
who:
§ Knows the business(es) and understand the data,
§ Knows why things are configured the way they are, and
§ Can make decisions on what is critical information and what is not
• Remember that Salesforce CRM is configured to support
your business processes
§ Pick list values represent steps in a process (i.e., Opportunity
Stage values = your sales process)
• Determine how you will address different processes
§ Standardize on a single process (i.e., one set of sales stages)
OR
§ Implement separate processes for the different business/groups
(i.e., multiple sales processes)
| Copyright © ShellBlack.com
14. Process & Access Review
• Record (page) presentation
§ Page layouts, record types, required fields, dependent picklists
• Object & field level security, record access and record
ownership
§ Updates needed to the security model (object access, field access,
sharing rules)
§ Determine record ownership
§ Review the Role Hierarchy (impacts reporting, e.g. “My Team: and
record access)
§ Profiles and permission sets for Users (e.g. User A in their old org
could mass email, import contacts from Outlook, and manage
dashboards – should they still be able to in the new org?)
14
| Copyright © ShellBlack.com
15. Agenda
• Single Org Benefits, Opportunity & Challenges
• Project Team
• Systems Review
• Process & Access Review
• Data Considerations
• Migration Strategy
• Migration Tools
• Next Steps
• Appendixes
15
| Copyright © ShellBlack.com
16. Data Considerations
• The next big phase in planning an org migration is to make decisions
around the data
• Addressing duplicate records
§ There will most likely be overlapping/duplicate data
§ Will need to be done either before or after you import the data from one
system into the other
– Prior to importing into master account
• Export both data sets, merge into one and identify duplicates
• Merge/delete duplicates, import clean file
– After importing into master account
• Leverage de-dupe tools in Salesforce CRM
• Leverage de-dupe tools from partners (see the AppExchange)
• Use a custom field to flag each records source system
• Develop rules for merging data
§ When there are two records for the same entity (i.e., Account), which one
‘wins’?
– Newest record? Most complete record? Record from one of the databases?
Most recently updated?
§ Determine who will own the records if there are duplicates
– Impacts sharing rules, reporting, etc.
– Leverage for data cleansing that will ensue
| Copyright © ShellBlack.com
17. Data Considerations
• Establish plan for migrating data
§ Determine when master system becomes live/
system of record (i.e., stop entering data into other
system)
§ Set date when you will extract all data from the
system being merged
§ How long will the merge take? How will you deal
with interim data? New data blackout dates?
Temporary data ID? (i.e do we need to plan for a
“Delta” update)
§ Ensure you have a complete copy of both data
sets before attempting any merging … just in case!
| Copyright © ShellBlack.com
18. Data Considerations
• The good news is that the data model is the same, but there is still a lot
of detailed and tedious work to create mapping tables
§ Every record in Salesforce CRM is assigned a unique 18-digit alpha-
numeric, case sensitive id by salesforce.com
§ 15 character IDs generated from a Salesforce report are not unique when
using the vLookup function (Excel is case insensitive). You can use the
CASESAFEID formula to translate the 15 character ID to a 18 character key
and export to a report, or use the Data Loader to export a 18 character key
§ Relationships between records are established based on these IDs (i.e.,
Activity related to a Contact)
§ These IDs will change when you import data from one system to another, as
the system will assign it a new ID
§ In order to re-create the relationships between records (i.e., import Activities
and associate to the appropriate Contact), you need to create a mapping
table that will allow you to associate the OLD Contact ID with the new one
§ Create a temporary/mapping field on each object you will need to map for
the old id (i.e., OLD ACCOUNT ID, LEGACY ID)
§ When importing the data into the master Account, map the Account Id to the
OLD ACCOUNT ID field
§ You will then be able to export the new Account Id, OLD ACCOUNT ID and
Account Name to act as your mapping table
| Copyright © ShellBlack.com
19. Data Considerations
• Created Dates
§ All records imported/migrated will have a Created Date = to when the import
occurs
§ You can ask Salesforce to enable access to the Created Date and Last Modified
Date fields via the API (i.e. the Data Loader)
• History Tables
§ Stage History for Opportunities / Case History for Cases
§ Data cannot be migrated into these tables, this information must be stored
elsewhere (e.g. a read only custom object) if you bring it over (“Note” field is not
reportable, so custom field is recommended)
• Unique Ids (system generated)
§ Record Ids are unique and cannot be imported
§ Imported records are assigned new Id, it is a good idea to import the old Id into
a custom field for mapping purposes
§ Features that reference (i.e., Custom Links) unique ids of other objects (i.e., a
report) must also be updated
• Record Types
§ If one of the Salesforce CRM instances leverages record types, all records
added from the other instance must be assigned a Record Type
§ Record Types can be updated through the API, not through the import wizard
§ Record Type assignment must also be aligned with user Profiles
| Copyright © ShellBlack.com
20. Data Considerations
• What if data is inadvertently …
§ Deleted
– Restore from the Recycle Bin – records are held for 15 days before they
are permanently deleted. Your recycle bin record limit is 25 times the
Megabytes (MBs) in your storage. For example, if your organization has
1 GB of storage then your limit is 25 times 1000 MB or 25,000 records
– Restore missing data from backups
§ Merged
– There is no way to “un-merge” data
– Clean up/work with merged records, OR
– Delete and restore from back ups
§ Imported incorrectly
– Mass transfer (if you can)
– Update records (if you can)
– Delete and re-import into proper area
– Consider tagging batches with a custom field indicating the load/batch
number in case you need to reverse
| Copyright © ShellBlack.com
21. Agenda
• Single Org Benefits, Opportunity & Challenges
• Project Team
• Systems Review
• Process & Access Review
• Data Considerations
• Migration Strategy
• Migration Tools
• Next Steps
• Appendixes
21
| Copyright © ShellBlack.com
22. Migration Strategy
• The last component of a successful org migration is creating your migration strategy
• Establish project timeline, team and project sponsor
• Determine changes that need to be made (configuration and procedural) and
implement on master instance
• Identify data to be retired/archived and not merged
• Communicate to end users upcoming changes, reasons, and benefits to them
• Extract data from other instance and cleanse (merge)
• Plan for post cutover cleanup
• Users will find things the team has missed!
• Reports and dashboards will need to be updated / reconstructed
• Check Date Ranges (i.e., Create Date and Original Create Date)
• Other filters on existing reports must be reviewed to ensure they are still
relevant/apply to all data
– KEEP BACKUPS OF BOTH SYSTEMS
| Copyright © ShellBlack.com
24. Recommended Update Order
Order Object to Update Related To
1 • Accounts
2 • Contacts • Accounts
3 • Opportunities • Accounts
• Contacts
4 • Products
5 • Product Line Items • Opportunities
• Products
6 • Cases • Contacts
7 • Leads
8 • Campaigns
9 • Campaign Members • Campaigns
• Contacts
• Leads
10 • Contracts • Accounts
• Contacts
11 • Assets • Accounts
• Contacts
• Cases
• Products
12 • Solutions • Cases
Depends • Custom Objects • Depends on implementation
Last • Activities • Can be to any standard or custom object
| Copyright © ShellBlack.com
25. General Issues to Remember
• Challenging to populate system generated dates
• Inability to import into Opportunity Stage History, Case History, HTML
Email Status
• Potential for duplicate data
• Folder access – Email, Reports, Dashboards, Document folders
• Naming conventions (e.g. Workflow Rules, Profiles, Reports, etc) –
be consistent!
• Values for Opportunity Contact, Sales Team, Case Team, Account
Team, and Partner Roles will be global
• Watch out for governor limits (e.g. max # of Workflow Rules, # Roll-
ups)
• Scheduling an org migration between major Salesforce releases is
not advisable
| Copyright © ShellBlack.com
26. Impact to Users and the Business
• Even with the best planning, expect some disruption
• Acknowledge upfront - something will get overlooked (and it may not be
discovered until days later)
• Every member of the team will not be aware of every nuance in the
configurations (it took years to build!)
• The risk of User disruption increases with the number of people making
changes to the configuration and importing data, and the amount of
customization in both orgs
Disruption can be mitigated by:
• Ensuring the right people are doing the right tasks (they have the
experience)
• Communicating appropriately within the team as well as to the Users
• Planning for some post-cutover cleanup as Users find issues
26
| Copyright © ShellBlack.com
27. Agenda
• Single Org Benefits, Opportunity & Challenges
• Project Team
• Systems Review
• Process & Access Review
• Data Considerations
• Migration Strategy
• Migration Tools
• Next Steps
• Appendixes
27
| Copyright © ShellBlack.com
28. Migration Tools
• Native Import Wizards (records)
§ Update or Insert records
§ Leads, Accounts & Contacts, Solutions, Custom Objects
§ Max 50,000 records
§ Not and ideal tool for an org merge
• Salesforce Data Loader (records)
§ Export, Update, Insert, Delete records
§ Standard Objects, Custom Objects, Activities, Attachments, etc.
§ Max 5MM records
§ See Appendix B for a complete list
• Metadata API (customization)
§ Custom Tabs, Workflow, Home Page Components and Layouts,
Permission Sets, Profiles, Reports, etc.
§ See Appendix C for a complete list
• Weekly Data Export (record backup)
§ Export all records including attachments, documents and Chatter files
zipped up in CSV files
§ Export Attachments
28
| Copyright © ShellBlack.com
29. When to use the Sandbox
• Staging everything in the Sandbox (data and
configuration updates) will add a lot of time to the
migration and will add little value
• Recommend using the Sandbox where the
deployment action would be irrevocable and could
have a financial business impact if done incorrectly
• Use the Sandbox to create and test new code
• Use for importing test records to validate mappings
29
| Copyright © ShellBlack.com
30. Documenting Your Org
• EasyDescribe (objects & fields)
§ http://appexchange.salesforce.com/listingDetail?
listingId=a0N300000018leZEAQ
• Field Trip (field usage)
§ http://appexchange.salesforce.com/listingDetail?
listingId=a0N30000003HSXEEA4
30
| Copyright © ShellBlack.com
31. Reconstruct vs. Migrate the
Configuration
• Though you can use the Meta Data API to recreate
some of the configuration, it might not be the most
efficient method
• For example, reconstructing a few workflow rules
would be easier to do using the UI (User Interface)
• However, a folder with 80 reports would be much
more efficient to migrate using the Meta Data API
§ Note - if any of the fields (columns) that are in a source report
are not present in the target org, the import will fail for that
report <-good example of why migrating using the Meta Data
API is challenging
31
| Copyright © ShellBlack.com
32. Agenda
• Single Org Benefits, Opportunity & Challenges
• Project Team
• Systems Review
• Process & Access Review
• Data Considerations
• Migration Strategy
• Migration Tools
• Next Steps
• Appendixes
32
| Copyright © ShellBlack.com
33. Next Steps
• ShellBlack.com, LLC will need logins to orgs
• Define Project Team and Roles
• Determine the workload capacity of internal team
(do you need more Admin staff?)
• Selection of first org to migrate
• Working Sessions to determine:
§ Forensic analysis of existing org (System Review)
§ Create the Project Plan
– Work Breakdown Structure / Task Assignments
– Calendaring the project / Critical Path
§ Scheduling Meetings with SMEs to begin Process Review
33
| Copyright © ShellBlack.com
34. Agenda
• Single Org Benefits, Opportunity & Challenges
• Project Team
• Systems Review
• Process & Access Review
• Data Considerations
• Migration Strategy
• Migration Tools
• Next Steps
• Appendixes
34
| Copyright © ShellBlack.com
35. Appendix A – Configuration Areas that
cannot be Migrated
35
| Copyright © ShellBlack.com
36. Configuration areas that must be
manually recreated
Account Contact Roles Contracts Settings
Account Partner Roles Delegated Administration
Dependent picklist rules
Account Teams Email Bounce Administration
Activity Button Override Email-to-Case
Activity Settings Fiscal Year
Approval Process Forecasts
Auto-number on Customizable Standard HTML Document and Attachment Settings
Label Renames
Fields Lead Assignment Rules
Business Hours Lead Processes
Call Center Case Contact Roles Lead Settings
Campaign Influence List Views on Standard Objects
Case Assignment Rules Ideas Comment Validation Rule
Ideas Communities
Case Team Roles
Ideas Settings
Case Escalation Rules
Console Layouts
36
| Copyright © ShellBlack.com
37. Configuration areas that must be
manually recreated cont.
Mail Merge Templates Predefined Case Teams
Mobile Administration Product Schedule Setup
Product Settings
Mobile Users and Devices Public and Resource Calendars
Offline Briefcase Configurations Public Groups
Opportunity Big Deal Alert Queues
Opportunity Competitors Role Hierarchies
Opportunity Contact Roles Salesforce to Salesforce
Sales Team and Account Team Roles
Opportunity Sales Processes Search Layouts on Standard Objects
Opportunity Settings Search Settings
Opportunity Update Reminders Self-Service Public Solutions
Organization Wide Defaults Self-Service Web-to-Case
Partner Management Self-Service Portal Settings
Self-Service Portal Users
Picklist Standard Fields—custom picklist
Self-Service Portal Font and Colors
fields on standard objects work in the Sharing Rules
Metadata API, but not standard picklists Solution Categories
37
| Copyright © ShellBlack.com
38. Configuration areas that must be
manually recreated cont.
Solution Settings
Solution Processes
Support Processes
Support Settings
Support Auto-Response Rules
Tab renames
Tag Settings
Territory Assignment Rules
User Interface Settings
Web Links on Person Account page layouts
Web-to-Lead
Web-to-Lead Auto-Response
38
| Copyright © ShellBlack.com
39. Appendix B – Data Loader Objects
39
| Copyright © ShellBlack.com
42. Appendix C – Meta Data API Objects
42
| Copyright © ShellBlack.com
52. ShellBlack.com, LLC
• ShellBlack.com, LLC is a Salesforce Cloud Alliance
Partner located in Dallas Texas
• Our goal is to help companies maximize their CRM
investment by providing elegant Salesforce
solutions that facilitate how you market, sell and
support your customers
• For Salesforce news, updates and information
follow us on Twitter: @Shell_Black
• Learn more about us online at:
www.ShellBlack.com
52
| Copyright © ShellBlack.com