Upgrading from Aspen - Dublin - any tips?

[Stig Brandt2]

Hi

I'm just going to upgrade our MSP solution from Aspen to Dublin, and was wondering if any of you had some tip/tricks, you could share?

Thanks in advance

Stig

[sbailey1]

Wow, that's quite a jump, Stig!   I think you and your users will be very happy with the new features and functionality in the Dublin release once you get there.   Here is the high-level approach I use:

Goal:   Upgrade without breaking any functionality you currently leverage

Restrictions: This is an upgrade project.   There are a lot of shiny new things in each release, but they are NOT part of an upgrade project.   Keep focus tight and don't allow wandering.

1. Identify all applications in use.   For each application, list critical functions by role.

2. List out all significant customizations and integrations in place along with roles / critical functions for each of those.

3. Prepare test plans to use for upgrade testing.   Mark these by priority.   Include any domain-specific customizations.

4. Prepare a sandbox instance for upgrade testing by cloning PROD to Sandbox.   Be sure to include email and audit data.   (You're going to need to keep a close eye on indexing with a jump like yours.   The closer you can get the clone to your PROD, the better.)

5. Prepare your release plan and sprints.   Start a draft of a release plan to include ordered release tasks with timings, update sets to apply, and manual steps along with the standard release planning information.   Allocate time for at least 1-2 trials on a sandbox BEFORE upgrading DEV.   I plan for trial 1, trial 2, DEV, TEST, PROD.  

Pre-populate tasks for each to include: clone environment, upgrade, run package call removal tool, develop and / or apply update sets, validate instance upgrade (which should have testing tasks for each application / integration / core function / etc.)

6. Prepare your team by allocating each a set of applications to "own" from a testing perspective and communicating expectations.

7. Once the clone to an instance is complete, upgrade the instance.   Record the step and time in draft release plan.

8. Execute the package call removal tool (Using the Packages Call Removal Tool - ServiceNow Wiki). Record the step and time in draft release plan.

9. Initiate testing, tracking test results in testing tasks.   Give testers a specific deadline and, if things like this typically fall to the wayside, schedule group testing time to "help" your testers focus.

10. Evaluate any failures or issues.   Ask:

- Can you replicate the same issue in PROD or another pre-upgrade instance?   If so, log a general defect.   This is NOT related to the upgrade and NOT in scope for this project.   Your testers will likely come across many such defects, so you will have to be very clear that we're focusing ONLY on defects that are a direct result of the upgrade.

- Is this defect critical?   Is it not possible to deliver <relevant business service> without this working?   If it is critical, address it.   If it's not critical, make a decision as to whether it will be fixed during the upgrade or just put in the product backlog to be addressed later.

11. If fixes are addressable by your development team, have them create an update set to address the issue.   Re-test to validate and save off the update set to XML to leverage during the next trial.   Record the step and update set name in the release plan.   If not fixable by your development team, escalate to HI if appropriate.

12. Once all tests pass, close the sprint and prepare the next instance.

For each sprint, update and refine the release plan.   By the time you upgrade PROD, you should be able to nail the time required to within a 20 minute window, but always give yourself plenty of extra.  

Hope this helps.   I know it's not domain-specific.   If you have questions or concerns about specific domain-separation functions to be upgraded, please reply.

- Stacey Bailey

[Stig Brandt2]

Hi Stacey

Thanks for your reply, and yes quite a jump, I have just taking over the responsibility of our MSP instances, but have a good knowledge of dublin features, but not from a domain perspective, in which I'm quite new.

do you know of any insights / best practices regarding, but maybe my questions is due to lack of my knowledge

- groups / roles

I would like to have global groups, with sudden access roles and make these available to domains, so the companies, them selves can assign specific roles by adding them to the global groups?

email   properties domain specific sending / receiving

I would like to have each domain should have own email for incoming/outgoing, is that possible?

best regards

Stig

[sbailey1]

Groups / Roles

- Having global groups to allow assignment from all domains is a common setup for escalation and global support groups.   Typically, though, during implementations, we incorporate safeguards on such groups to tightly control membership and (should) rarely use those groups to assign roles, so you don't wake up and find your clients have tripled your license count and promoted themselves to be on your central support teams.

- For role assignment with clients, the approach I like is to create standard security groups for each client on-boarded.   I set a common parent group to all with the role(s) appropriate to the group, so the roles filter down to all child groups.   That parent group doesn't need to be in global, though, for the role inheritance to work.   This allows me to centrally control security rights by group across my client base.

- You may also want to look at https://wiki.servicenow.com/index.php?title=Role_Delegation to see what other types of controls you may want to put in place.

- If you allow customers to grant roles to others within their domain, just be sure that you have reporting and monitoring mechanisms in place to keep a close eye on it.

eMail Properties - domain specific sending and receiving

- Using the http://wiki.servicenow.com/index.php?title=Email_Accounts plugin, you can have ServiceNow check a different mailbox per company.   This makes the task of sorting emails into the right domain light-years easier than it used to be.  

- Sending from the system is still (as of Calgary), limited to just a single outbound account.   Trying to change the 'from' address will likely make malware / email monitoring systems light up like christmas trees, so what we do in this case is allow customers to specify the 'from' display name they want to show and set a reply-to address.