Lightning Migration Overview Follow
Propertybase "Lightning" is a completely redesigned user experience; featuring a faster, modern user interface. Migrating from Propertybase Classic (the original version of Propertybase), to Lightning will allow you to work faster and smarter. Propertybase Lightning customers also receive the latest updates and newest features. Best of all? Lightning is completely free to all Propertybase customers.
Please review all the information below before starting the migration process.
Deprecated Features
While most features exist in both versions of Propertybase, there are some features that were deprecated and do not exist in Lightning. The "accordion" sections below contain a list of those features, please click on one of the sections below to view deprecated features separated by version. If you have any concerns regarding deprecated features, please contact Propertybase Support.
v1.9 - v1.244
| Deprecated Propertybase Features | Deprecated Salesforce Features |
|
|
v1.245 - v1.353
| Deprecated Propertybase Features | Deprecated Salesforce Features |
|
|
v1.354 - v1.399
| Deprecated Propertybase Features | Deprecated Salesforce Features |
|
|
Sandbox vs Production
Migrations can be performed two different ways: first in a sandbox and then in production, or one time directly in production. Please review both methods below to determine which is best for your specific organization. Once you have reviewed below, you can create a Sandbox by following the first tab in this article.
Sandbox Migration
A sandbox is an exact copy of your Propertybase account. A sandbox is a tool used to test new changes, configurations, integrations, etc. Below are a few reasons why performing the migration in a sandbox first may be a good choice for your organization.
Your organization has custom code or specific configurations. If your organization has made customizations to your Propertybase account, performing the migration in a sandbox first is highly recommended. This will allow you to test those configurations extensively in a safe environment at your own pace.
You can perform the migration at your own pace. This is because when you make changes to a sandbox, your real account remains unchanged. Users can continue to use your Propertybase account while you make changes in the sandbox. Alternatively, when performing the migration directly in production no one should be in the system and no data should be modified or changed during the migration process.
You don't risk making your account unusable for a short period of time. Part of the migration process requires you to submit a ticket to Propertybase Support. Although we make every effort to respond as quickly as possible (migration requests are considered very high priority), there may be a short delay in our response. When performing the migration in a sandbox, this short delay has no affect because you can continue to use your production account normally. Alternatively, when performing the migration directly in production your entire account will become unusable until our support team is able to assist your request.
You will be able to perform the production migration much faster. This is because you will have already performed the entire migration in a sandbox. Performing the migration a second time in production will allow you to work much faster, causing less downtime for the rest of your organization.
Production Migration
Even after considering all of the points above, performing the migration directly in production is still a viable choice. Below are a few reasons why performing the migration directly in production may be a good choice for your organization.
Your organization uses Propertybase "as is" out of the box, with no customizations. If your organization uses the standard Propertybase experience with no extra addons, integrations or custom code you won't need to do much testing.
You consider yourself a power user. If you consider yourself an advanced Propertybase user and tech savvy, then you might not need the practice that a sandbox migration offers.
You want to save time. Performing the migration directly in production will significantly lower the amount of time a migration takes. This is because you aren't performing the entire process twice. A production migration will take approximately 6 to 8 hours to complete, while performing the migration in a sandbox first will increase that to almost 12 hours.
Custom Components
If your organization has made significant customization to its Propertybase account, please review the following considerations prior to migrating.
- Custom Classic Buttons need to be redeveloped for Lightning as they will no longer function properly.
- Custom Visual Force Pages need to be redeveloped for Lightning as they will no longer function properly.
- Custom Apex Triggers should continue to work in Lightning, so long as there are no UI elements and all info is still in use. Custom apex triggers that have UI elements will need to be updated for the Lightning interface or they will no longer function properly.
FAQs
What if I don't upgrade to Lightning?
Staying on Propertybase Classic and using your account in its current form is an option. However, you will not recieve any improvments or new features from Propertybase. Likewise, neither Propertybase or Salesforce will be able to assist you with any bugs or problems with your account.
How long does the migration process take?
Typically 8-12 hours for a sandbox/production migration or 6-8 hours for production only. However Propertybase administration knowledge, technical ability and any customizations will all effect migration duration.
Once you have reviewed the information above and determined you're ready to start, the PDF documentation attached below will guide you through the migration process, step-by-step. Please allow yourself approximately 8-12 hours for sandbox migrations and approximately 5-8 hours for production only migrations.
Documentation Last Updated: June 15th, 2018 (v1.9)
1.9
- Configuring object settings now happens before updating to PB version 1.414. (section 4, formerly 6)
1.8
- Removed deprecated Lightning actions.
- Changed the Login Box height from 320 to 310. (section 5a)
- Added section about allowing browser popups. (section 5b)
- Added "Send Email" custom button. (section 11)
- Reduced steps in "Configure Page Layouts" section and moved it. (section 12, formerly 7)
1.7
- Added new section regarding required fields. (section 9)
- Updated section on process builder to reflect new internal scripting tools. (section 14)
- Brought wording inline with recent Salesforce updates.
1.6
- Added troubleshooting appendix.
- Added additional screenshots and clarification updates throughout.
1.5
- Added instructions for manually exporting custom list views. (section 3b)
- Added instructions for manually importing custom list views. (section 17a)
1.4
- Removed 'New Showing' action from Closing object. (section 11a)
- Updated sandbox instructions to use a 'partial' sandbox. (section 1a) (More info: a partial sandbox includes sample records which improves ability to test account functions in a sandbox prior to migrating in production. Previous documentation instructed users to use a 'developer' sandbox.)
1.3
- Fixed missing images. (section 10)
- Added helpful tips for creating "fake" records on certain objects. (More info: when creating a new sandbox account, only configuration settings are copied over from production - no record data is copied. Some steps in the migration process require you to open a record. Because of this it is sometimes necessary to create "fake" records.)
1.2
- Added instructions for updating the branded layout Quicksend template. (section 4d)
1.1
- Added configuration steps for custom duplicate matching. (section 8e)
Comments
0 comments
Article is closed for comments.