Office365 Enterprise Transition Guide en v2.2

BPOSS to Office 365 Transition
Transition Planning Guide for Enterprises
Published: July 2012

Document Version 2.2
The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the
date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment
on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.
This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO
THE INFORMATION IN THIS DOCUMENT.
Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of
this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means
(electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of
Microsoft Corporation.
Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject
matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this
document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.
2012 Microsoft Corporation. All rights reserved.
Microsoft, ActiveSync, Active Directory, Entourage, Forefront, Internet Explorer, Lync, Outlook, SharePoint, Windows, Windows Phone,
Windows Mobile, Windows PowerShell, and Windows Vista are trademarks of the Microsoft group of companies.
All other trademarks are property of their respective owners.
BPOS-S to Office 365 Transition Planning Guide for Enterprises 2

Contents
Section 1: Overview and Executive Summary...........................................6
Introduction............................................................................................................. 7
Overview of the Transition...................................................................................... 7
How Office 365 Services Map to BPOS Services......................................................8
How to Use this Guide............................................................................................. 8
Document Scope and Limits................................................................................. 8
Customer Environment Assumptions..................................................................10
Transition Responsibilities.................................................................................. 11
Implementation Team......................................................................................... 11
Assumed Knowledge.......................................................................................... 13
Office 365 Trial Subscription.................................................................................. 15
Feedback............................................................................................................... 16
Section 2: Transition Tasks and Timeline................................................17

Overview............................................................................................................... 18
User and Administrator Impact During the Transition Weekend.........................18
Transition Support.............................................................................................. 20
Customer Responsibilities.................................................................................. 20
Transition Phases and Milestones..........................................................................24
BPOS Pre-Transition Phase.................................................................................. 26
Pre-Transition Phase Key Activities.....................................................................26
Office 365 Transition Phase................................................................................ 28
Office 365 Transition Phase Key Activities..........................................................29
Office 365 Post-Transition Phase........................................................................29
Post-Transition Phase Key Activities....................................................................30
Detailed Transition Timeline..................................................................................31
(Earlier than T-60 Days) to Transition.................................................................31
(T-60 Days) to Transition..................................................................................... 33
(T-2 Days) to Transition....................................................................................... 36
(T-0) Transition Start (Friday 3 pm local time in the most western time zone for
your region)........................................................................................................ 37

(T-00) Transition Complete (No later than Monday 3 am local time in the most
western time zone for your region)....................................................................37
(T+8:00 Hours) Post Transition (Approximately the first business day after
transition)........................................................................................................... 39
(T+72:00 Hours) Post Transition.........................................................................39
(T+84:00 Hours) Post Transition.........................................................................40
(T+2 Weeks) Post Transition............................................................................... 40
Section 3: Technical Considerations.......................................................41

Overview............................................................................................................... 42
Software Requirements......................................................................................... 44
Operating system requirements.........................................................................44
Office client requirements.................................................................................. 44
Browser requirementsAdministration Center and My Company Portal............44
Browser requirementsOutlook Web App..........................................................44
Sign In Credentials................................................................................................ 45
Required Password Changes................................................................................. 45
Software Deployment and Packaging....................................................................46
Manual Distribution of Client Updates................................................................46
SharePoint Version Differences............................................................................. 47
Lync Deployment.................................................................................................. 47
Live Meeting.......................................................................................................... 48
Configure Internet Explorer...................................................................................49
Update DNS Settings for Outlook..........................................................................50
Authentication....................................................................................................... 50
Microsoft Online Services Sign In Client.............................................................50
Single Sign-On.................................................................................................... 50
Service Connectivity............................................................................................. 51
Mobile Devices...................................................................................................... 51
Mail-Enabled Applications..................................................................................... 52
Message Routing and FOPE...................................................................................52
Exchange Hosted Archive (EHA)...........................................................................53
Blackberry (RIM) Devices...................................................................................... 53
SR Review............................................................................................................. 54
Migration of Settings and Configuration................................................................55
Network Bandwidth Reassessment.......................................................................56
Determination of Administrator Roles...................................................................57

Deploy Directory Synchronization for Office 365 Post Transition...........................58
Preserving Public Delegates.................................................................................. 59
Converting Shared Mailboxes................................................................................59
Section 4: Client Experiences................................................................61

Portals................................................................................................................... 62
End-User My Company Portal............................................................................. 62
Administrator Microsoft Online Admin Center (MOAC)........................................64
Section 5: Appendices..........................................................................66
Appendix A: Post-Transition Resources..................................................................67
Post Migration Service Testing Activities............................................................67
Validate URLs for Office 365............................................................................... 67
Office 365 SMTP Relay Changes.........................................................................68
Testing Collaboration Services Client Workstations.........................................68
Testing Collaboration Services Exchange Online..............................................68
Testing Collaboration Services SharePoint Online............................................69
Testing Collaboration Services Lync Online......................................................69
Post-Transition Activities..................................................................................... 70
Appendix B: Transition URLs, Ports and IP Addresses for Office 365.....................71
Office 365 Portal................................................................................................. 71
Microsoft Online Services Sign In.......................................................................71
Required Ports.................................................................................................... 72
Appendix C: External Document References.........................................................74
Appendix D: Glossary of Terms.............................................................................. 77

Section 1: Overview and
Executive Summary

Introduction
The Microsoft BPOSS to Office 365 Transition Guide for Enterprises is intended to
help you understand the requirements and work streams for transitioning your
organization from Microsoft Business Productivity Online Standard Suite (BPOSS) to
Microsoft Office 365 for enterprises, using the automated Microsoft transition process.
This transition of your production tenant moves user data and settings to their
functional equivalents in Office 365, while maintaining service to your users
throughout the change.
As an enterprise IT administrator running a BPOSS tenant (e.g., over 1000 users),
you should understand that there are multiple work streams required in your
organization in order to smoothly achieve transition. The more sophisticated your IT
systems are, the more work will be required to confidently complete the work
streams. This document is designed to help you determine and plan the work streams
necessary in transition strategy.
This document is offered as a complement to existing information sources and does
not replace the Microsoft Office 365 Deployment Guide for Enterprises (MODG), or the
Office 365 Service Descriptions that are already published.
Overview of the Transition

There are three phases of transition:
Pre-transition. Because the transition of service from BPOSS to Office 365
will have a significant impact on the consumers of the service, and also on how
IT provides services and functionality based on the feature set in the service, it
requires a level of planning equivalent to any major technology infrastructure
change. The planning and readiness work required to prepare for transition is a
customer-owned work stream that must be started many weeks before you
have been notified by Microsoft of the transition of your service.
Automated transition. The automated transition process has tasks that
Microsoft does in the background in the weeks prior to the actual transition,
and then the actual transition of user accounts and data typically occurs over a
weekend and may take 48 hours to complete.
Post-transition. Once the automated transition is complete, the post-
transition phase involves customer-owned validating and testing based on the
plans prepared in the pre-transition phase.
For a detailed timeline including key tasks for each phase, see Section 2, Transition
Phases and Timeline.
Microsoft will schedule the automated transition process for your organization
between now and September 2012. After reading this document and determining your
organizations timeline for pre-transition tasks, please contact your Microsoft
representative to let them know when your organization will be ready for transition.
Important:

There is no ability to cancel, roll back, or indefinitely suspend transition once
the transition is in the Microsoft pipeline. Microsoft will provide all customers
the one-time ability to postpone the transition by 60 days, if necessary. Such a
postponement must be requested before you reach the T-14 day milestone. You
must be prepared and staffed to address any post-transition issues within the
context of the Office 365 service until everything is working as expected.
Attempting a manual production transition to Office 365 is not supported by
Microsoft and runs the risk of inbound email loss, stored email and
configuration settings loss, and compromised email archives. A manual
transition approach takes longer and adds additional work to that described in
this guide for a Microsoft scheduled transition, and significantly increases the
risk of disruption for your end users.
The project work described in this document is essential to ensure a smooth
transition and to reduce IT and business-related issues after transition.
How Office 365 Services Map to BPOS

Services
Microsoft Office 365 for enterprises is the successor to BPOS-S, which was the first
generation of cloud-based multi-tenant business productivity offerings from Microsoft
Online Services.
The Office 365 for Enterprises solution includes the following cloud-based services:
Microsoft Exchange Online (maps to Microsoft Exchange 2007 in BPOSS)
Microsoft SharePoint Online (maps to Microsoft SharePoint 2007 in BPOS-S)
Microsoft Lync Online (maps to Microsoft Online Communicator Service (OCS
2007 R2) in BPOSS, and replaces Microsoft Live Meeting)
Microsoft Office 2010 Professional Plus (New for Office 365)
The cloud-based solutions in Office 365 for Enterprises are based on the 2010
versions of Microsofts server products, but are not functionally identical to the on-
premises software versions. The Office 365 Service Descriptions are the definitive
source for understanding the Office 365 services, and are available for download at
http://www.microsoft.com/download/en/details.aspx?id=13602.
How to Use this Guide

This document has been organized into sections that provide information for specific
types of deployment personnel in your organization. Here is a quick overview of what
you will find:
Section 1: Overview and Executive Summary. This section describes
important concepts and assumptions that are essential for planning your
transition, including using a trial Office 365 tenant to explore and test Office
365.
Section 2: Transition Tasks and Timeline. This section provides a look at
the key customer accountabilities in the Microsoft scheduled transition process
and the organizational requirements to successfully transition from BPOS to

Office 365. The information is presented in two ways: by work stream for each
phase, and by detailed timeline. We recommend that your IT department build
an overall IT change plan that comprehensively addresses all the topics
covered in this section.
Section 3. Technical Considerations. This section provides the technical
details for the tasks referenced in Section 2.
Section 4. Appendices. The appendices contain reference information
mentioned in the preceding sections.
This document describes the transition process for all the BPOSS services. If you
have not subscribed to a service, you can disregard sections of the document that
apply to services you have not subscribed to.
Document Scope and Limits

This document is specifically focused on the transition from BPOSS to Office 365, in a
production IT environment that is already configured and has deployed the BPOSS
service in production use today.
The document does not address the following items, as these are covered and
referenced in existing published guidance or guidance will be published at a future
time.
Migration of on-premises email to any online service. You should be
finished with all on-premises to cloud migrations before transition. If you cant
finish a migration, you will need to stop it, and then migrate the remaining
mailboxes directly to Office 365 after transition. For more information on
options, see Pre-Transition Key Activities.
Upgrade of BPOS Dedicated (BPOS D) to Office 365 for enterprises
dedicated plans. The dedicated plans are entirely different than the services
described in this document. Because the environments for dedicated plans are
limited to a single customer, upgrades are conducted on a customer-by-
customer basis.
Review of the Office 365 service descriptions to ensure business
alignment. Your organization should not move forward with its planned
transition to Office 365 until all aspects of the service have been evaluated for
alignment with your existing business and IT requirements, and you understand
the impacts and complexities involved in the service transition, as well as the
changes in the Microsoft service offering that will lead to material changes to
your IT service offering to users. We recommend reviewing the BPOSS service
descriptions and the Office 365 service descriptions at the same time to
compare differences directly.
o The Office 365 for Enterprise Service Descriptions can be found at
http://www.microsoft.com/download/en/details.aspx?id=13602
o The BPOSS Service Descriptions can be found at
http://www.microsoft.com/download/en/details.aspx?
displaylang=en&id=18459
Validation of BPOS user licenses. To successfully transition to Office 365,
your organization will need to have a tenant with a current, paid subscription.
BPOSS tenants currently in use for testing or validation will not be

automatically transitioned if they are based on trial subscriptions. Microsoft will
typically only transition paid tenants to Office 365. Microsoft recommends that
customers review and document their subscriptions and ensure that tenants
they want to maintain, such as production test environments, are eligible to be
transitioned to the new service. If you are uncertain about the status of a
BPOSS tenant subscription, or if you have a production test or content
development tenant that is still using a trial subscription, please contact your
Microsoft representative.
Office 365 feature enhancements that occur after transition. This
document does not include implementation guidance for any features of Office
365 that dont have equivalent functionality in BPOSS. For example, Office 365
offers single sign-on based on ADFS (Active Directory Federation Server), and
also offers hybrid cloud and on-premises mail scenarios. All new features are
unavailable for implementation until you are fully transitioned to Office 365.
Other details of implementing Office 365. The Microsoft Office 365
Deployment Guide for Enterprises (MODG) is a good reference for the technical
configurations in the service. Even though the MODG doesnt directly deal with
transitions, the reference information provided in the MODG is useful for
understanding the deployment of the Office 365 service into your enterprise. To
download the guide, go to http://www.microsoft.com/download/en/details.aspx?
id=26509.
Transitioning from Exchange Hosted Archiving (EHA) to Exchange
Online Archiving (EOA). The EHA service will be unaffected as part of the
BPOSS transition process. However, the end of life for the EHA service has
been announced by Microsoft, and the EHA to EOA transition will be a separate
project, with Microsoft working with EHA customers to plan for the successful
transition of archiving services at a later date.
The transition guidance described in this guide is subject to change as Microsoft
makes improvements and enhancements to the transition process based on review of
each transition that occurs. Before starting work based on the advice in this
document, its important that you check for updated versions of this guide at the
Microsoft Download Center, at http://g.microsoftonline.com/0rmcm00en-us/5018.
Customer Environment Assumptions

The guidance in this document is based on the following core principles and
assumptions:
The Microsoft BPOSS service, and after your transition, the Microsoft Office 365
Service, is a subset of the end-to-end service offered by your IT department to
your business. You necessarily layer on and/or integrate with additional
internally operated processes and services, such as:
o User provisioning
o Help desk
o Desktop workstation technology, including laptop and PC devices
o Mobile devices

o Security services
o Business application software
o Business rules and services such as retention policies, legal discovery,
archiving, and mobile device policy
No change should be introduced by the IT services to the business, or to the
underlying IT infrastructure, that has not been evaluated for business fit and
tested for technical efficacy in the environment. For example, in large
organizations:
o The rollout of patches is usually tested to ensure there are no adverse
impacts to business functionality or IT customizations.
o The roll out of a new software version for any business user or business
process impacting workload is a non-trivial project in its own right,
including distinct evaluation, test and roll-out phases. For example,
simply changing the version of Microsoft Outlook that users use requires
validating that any Outlook plug-in components in use such as CRM,
encryption, or conferencing, will work and be supported by the plug-in
vendor. Such a change also requires training users and help desk staff,
and preparing new help content.
Change to IT services or technology typically requires sign off by multiple
departments (e.g. user advocacy, IT security, IT change management) and
these changes are usually organized, managed, tracked and implemented via a
change project.
Changes to the business functionality provided by IT services often require
evaluation by and sign off by the businesses that are impacted.
Enterprise-scale organizations typically have a substantial IT department that is
responsible to provide the end-to-end messaging and collaboration services to
the business.
Enterprise-scale organizations typically have too many users to manage their
technology on a user-by-user basis. Managed technology rollout approaches will
be in use already, with specific change-management approaches,
communications approaches, and use of desktop management technology for
any work that that touches the end-user workstations or enterprise servers.
Some of the IT work implicit in the above may be outsourced to vendors on a
permanent or staff augmentation basis.
Enterprise-scale organizations typically use a number of large application suites
with software environment dependencies (e.g. SAP, PeopleSoft, Siebel, Ariba),
and changes to simple things like workstation software or web browser can
have non-trivial consequences in these applications. Often such packages have
limitations on what changes can be introduced and still be supported (e.g. only
certain browser versions supported). Often the IT department is required to
manage these multi-vendor integration dependencies and choose the path of
perceived lesser risk as they judge it (e.g. stay on old browser version with
inherent security concerns or update browser to eliminate security concerns,

but in so doing risk being in an unsupported configuration by a key business
application vendor).
Even if all of the above principles and assumptions may not apply to your
organization, some of them may apply to a lesser or greater degree, and it is left to
the reader to determine which elements of the advice in this document should be
adopted in your transition project in order to successfully introduce this significant
change into your environment.
Transition Responsibilities
The automated transition from BPOSS to Office 365 is conducted by Microsoft under
our contractual obligations for BPOSS. Under this program, all Microsoft datacenter-
side activities are conducted in partnership with our customers, with the costs of
these transition items included in the service fees. The transition is designed to
provide for minimized production disruption to users and no loss of data or settings.
Where a technical trade off or choice was necessary between creating work for
customers IT departments or introducing impacts on end users, Microsoft has always
chosen to reduce or eliminate the impact on end user service. Of course Microsoft has
also tried to minimize your IT departments work. Most of the work you will need to do
will be based on your internet access, your software versions in use and any points of
customization you have introduced. You will have the most work to do if you have
heavily customized your usage of BPOSS or done things which Microsoft does not
support in BPOSS.
Demarcation of responsibilities between you and Microsoft can be described as
follows:
Microsoft datacenter-side transition work items are Microsofts responsibility
(including our internet connectivity).
Customer-side readiness work items are your responsibility (including your
internet connectivity).
Conversion of your business processes dependent on the service is your
responsibility.
Training of employees to use the new service is your responsibility.
Planning and coordinated execution is a joint responsibility.
Adoption of new Office 365 features is your responsibility after transition has
completed.
Implementation Team
The transition from BPOS to Office 365 is a multi-phase approach that requires close
communication and coordination of activities between your internal teams and
Microsoft Online Services. Depending on the services you have subscribed to with
Microsoft, your Premier Technical Account Manager (TAM) will be your central conduit
for planning and coordination of activities with Microsoft Online. For customers who do
not elect to have the services of a TAM, Microsoft will appoint a Service Transition
Manager (STM) to provide basic help with the communications and high level
activities leading up to the transition window. In either case, its important to
understand whats required of your IT team, so that proper planning and managed
changed activities can be taken into account to ensure a smooth transition

experience. Although your project personnel will have varied technical backgrounds,
they should have project management, service management, or technical support
backgrounds in addition to familiarity with the BPOS and Office 365 services.
The transition of service from BPOSS to Office 365 will have an impact on not only
the consumers of the service, but how IT provides services and functionality based on
the feature set in the service. Due to the breadth and depth of the transition
activities, Microsoft recommends that you allocate a technical project manager
responsible for the orchestrated execution of the IT change tasks identified in this
guide. Most enterprise IT organizations will already have an approach to production
software upgrade and change management of production IT services. In many large
enterprises, a number of different constituencies are impacted by a change in IT
services, all of which much be taken into account during the project planning phases.
The same approaches used for the upgrade of any other customer IT services should
be employed in this transition, and this document is intended to help your transition
team identify and integrate the required work streams into an overarching transition
project plan.
As part of a managed change approach, Microsoft recommends the formation of an IT
project team, with appropriate representation from each area of responsibility. The list
below provides an overview of the areas that are impacted by the transition. You
should also anticipate the uniqueness of your environment to ensure that there are no
additional impacts to services or processes. While Microsoft understands your
organization might not have dedicated teams for each of the topics summarized
below, you should ensure you have accountability for each of the areas in your team.
Networking and network security. Review port requirements, firewall rules
and settings critical to the adoption of the service across the enterprise, and
apply those changes without impacting production services. These teams will
also need to understand, and address any changes in bandwidth and circuit
requirements, as a result of the implementation of Office 365.
Security and policy administrators (Group Policy Security
Administration). Review the impact of changes in the service and required
policy changes to provide equivalent services during and post transition. In
addition to management of security policies and architecture, the security team
in many organizations is responsible for the management of certificates and
the PKI infrastructure which might be required depending on the organization
configuration.
Help desk. Your help desk will be a critical component of the transition
process, not only as a first response group for user concerns immediately after
transition has completed, but also because the help desk organization will be
impacted the most by changes in functionality in the services. Therefore in
advance of the transition, they will need to understand the impact that Office
365 presents on the services, processes and organization, train their staff and
prepare content.
Line-of-business application administrators. With the transition of the
service, its important to have identified any line-of-business applications
requiring messaging or other functionality in order to ensure a smooth
transition to Office 365, so that there is minimal interruption in the line-of-

business applications. In addition to the changes to applications that rely on
Office 365, planning for consequential changes to unrelated applications as a
result of these requirements should be planned for. For example, all Internet
Explorer and Outlook plug-ins need to be evaluated and tested as part of
preparing for transition.
Messaging and collaboration. Ensuring the messaging and collaboration
teams within the enterprise understand the transition process, and have
actionable plans in place will be critical to establishing customer expectations
during the whole transition process. A clear understanding and well-defined
communications plan will be critical to increase awareness, and communicate
changes to your user community in advance of the transition.
User advocates and user liaisons. A complete and robust communication
plan executed with the support of user advocates will help your user
community to prepare for the changes in service functionality and the
disruptions during the change period.
SharePoint administration and governance. From the point of view of the
users, the post-transition SharePoint environment will maintain the same visual
elements as the current BPOSS environment, until you choose to perform a
SharePoint 2010 Visual Upgrade. While the transition process is designed to
ensure customer workflows and business integration will work as expected,
Microsoft recommends that a testing plan be developed so that all functionality
can be captured and reviewed during the transition validation process.
Remediation plans for any non-functional pages or functionality will need to be
prepared.
Identity and directory teams. In order to ensure customer access over the
course of the transition and after, this team needs to plan for the transition of
identity and user information into Office 365. This includes provisioning and
change management for identity and user data.
Change management. Due to the large number of services and wide-spread
impact to the enterprise, inclusion of change management staff is a
requirement for a successful implementation. The change management team
should be tasked with providing a means of introducing change in a predictable
manner in the enterprise, through your previously established processes. If you
do not operate a specific change management team, you should still take a
careful managed change approach, with deliberate sign off of changes,
advance testing and a checklist of dependencies on each change that are
resolved before it is put into effect.
Assumed Knowledge
For the technical areas of the transition to Office 365 from BPOS, this guide assumes
that your organization has personnel with Microsoft Certified Systems Engineer
(MCSE) and Microsoft Certified IT Professional (MCITP) certifications or equivalent
skills. Your personnel should also have experience with Microsoft Exchange Servers,
Microsoft SharePoint Server, Microsoft Office Communications Server 2007 R2 or Lync
Server, the Windows Server operating system, and Active Directory Domain Services.
A detailed list of assumed technical knowledge is provided below.
Knowledge and proficiency in the following Microsoft technology areas:

o Active Directory Domain Services
o Microsoft Exchange Server 2010, Exchange Server 2007, or Exchange

Server 2003
o Microsoft Lync Server 2010 or Microsoft Office Communications Server
2007
o Microsoft SharePoint Server 2010 or Office SharePoint Server 2007
o Microsoft Live Meeting
o DNS and related technologies
o Windows PowerShell 2.0
o Internet Information Services ((IIS) 6 or higher
Knowledge and proficiency in the following Microsoft client technologies:
o Microsoft Office 2010 and Office 2007
o Windows Internet Explorer 7 or higher and other Internet browser

technologies
o Windows Update and Microsoft Update
o Mobile Devices
Knowledge of the customer network topology:
o Active Directory sites, trusts, and topology
o Local Area Networks (LANs) and Wide area Networks (WANs): on-
premises networks and equipment
o Wide area Network connectivity: Internet bandwidth and latency
o Firewall/Browser Proxy technologies
o SSL certificates
Knowledge of the existing messaging systems currently deployed, for example:
o Microsoft Exchange Server-based systems
o Microsoft BPOS Standard based Messaging Environment
o POP3/IMAP4/SMTP-based mail systems
o Lotus Notes Domino
o Novell GroupWise
o Mail Archival systems
o Email encryption

In addition to the technologies listed above, its important to be aware of the changes
in each service for Office 365, and the available online resources that can be used to
assist in planning and transition. Microsoft strongly recommends that the virtual team
begins reviewing the appropriate service descriptions in order to understand the
technical changes within the service, in addition to planning for changes in
administration and service usage.
In addition to reviewing the Office 365 Service Descriptions, you should read and
understand the following articles:
Office 365 Frequently Asked Questions:
http://www.microsoft.com/en-us/office365/faqs.aspx
Office 365 release notes:
http://community.office365.com/en-us/w/release-notes/default.aspx
Transition checklist:
http://download.microsoft.com/download/A/6/4/A6479925-C7D2-4C4C-A21B-
48BCCF8887A9/Checklist_EN_191010.docx
Office 365 transition Frequently Asked Questions:
http://download.microsoft.com/download/A/6/4/A6479925-C7D2-4C4C-A21B-
48BCCF8887A9/FAQ_EN_101010.docx
In addition, for a complete list of all external references listed within this document,
see Appendix C: External Document References.

Office 365 Trial Subscription
One of the best ways to understand the nature of changes that will happen as a result
of the transition between BPOSS and Office 365 is to experience the software by
exploring Office 365 in a tenant that uses a trial subscription. Tenants based on trial
subscriptions are the functional equivalent of production tenants in most customer-
visible respects. Using a trial tenant also provides advance administrator access to
the Office 365 interface to help provide understanding and knowledge of the
environment before the actual transition date.
We recommend that all customers establish at least one Office 365 tenant based on a
trial subscription. This will allow administrators to experience Office 365 and help plan
for the transition. This trial account should only be used for testing (e.g. firewall and
access testing), integration customization design (e.g. advance preparation and test
of mobile devices ActiveSync policies), training preparation (e.g. end user training for
sign-in changes) and business process design work (e.g. Legal and eDiscovery).
Important: When creating an Office 365 trial account for testing and evaluating the
service in advance of transitioning from BPOS-S, keep in mind the following:
Data and configuration settings within trial tenants are not migrated to any
production Office 365 tenant after or during the transition. After the trial has
expired, all content, settings, and data in the trial will be irretrievably deleted.
Do not use the same tenant domain name that is in use in BPOSS currently, as
this will conflict with your production transition and cause the process to fail.
For example, if your BPOSS tenant is called
contoso.emea.microsoft.online.com you must not create an Office 365 tenant
called contoso.onmicrosoft.com.
You will not be able to use any of your existing SMTP or SIP domains in the
Office 365 trial tenant, and you should not attempt to use any other SMTP or
SIP domains that you are considering for use in Office 365 in the future.
If, as part of your testing, you import some mailboxes from your BPOS S tenant
into the trial tenant, and attempt to reply to the mail items you have imported,
such replies will fail to be delivered and you will see non-delivery reports. This
is because the mail addresses from your BPOS S email will be invalid in the
trial tenant, and is to be expected.
If, as part of your testing, you import SharePoint content into Office 365 and do
not re-factor the URLs in the content during that import, the content will not
work reliably in the trial tenant. In the transition to your production Office 365
tenant, Microsoft will add redirects to old BPOS S URLs to keep your content
working, giving you time post-transition to re-factor the URLs.
The kind of testing advised in this document is not the primary purpose for
which Microsoft offers a trial subscription for Office 365. Consequently you will
receive email messages and other communications from Microsoft encouraging
you to convert each trial tenant into a paid production tenant. These messages
are automated, have nothing to do with transition from BPOSS, and should be
ignored if a trial tenant is being used for transition evaluation and test
purposes. Unfortunately, at this time Microsoft is unable to correlate your trial

tenant with your status as a valued production customer or to suspend these
messages.
To sign up for an Office 365 trial subscription, go to http://www.office365.com.
Feedback
Readers are encouraged to submit feedback about this deployment guide to
[email protected]. Your feedback is important to the continued
improvement of this document.

Section 2: Transition Tasks and
Timeline

Overview
The guidance in this section is organized in two ways, by the work streams required to
implement the components that provide the foundation of the IT service to the
business, and by timeline (pre, during, and post-transition).
The first part of the section describes the impact during the transition weekend,
the support requirements, and the customer responsibilities and work streams
based on the Service Delivery Management (SDM) methodology. Microsoft
recommends using SDM or an alternative methodology in order to provide an
established set of guidance for planning, testing and transitioning the service
over the course of the project.
The second part of this section, Transition Phases and Milestones, lists the
key activities for the three phases of the transition.
The third part of the section, Detailed Transition Timeline, provides a
detailed timeline to help you understand the sequencing of tasks, and to ensure
your enterprise change processes align with the scheduled Microsoft
components.
The extent to which customer-side transition work items are necessary is dependent
on many factors including:
The extent of any customer side customizations which need to be redesigned,
tested and reapplied.
The extent to which customer side functionality depends on deprecated or
adjusted features and functions.
The status of the client computing environment relative to current software
versions.
The number of users in your tenant.
The sophistication of client side automation, comprehensive support systems
and other end-user impacting aspects of the customers IT environment.
User and Administrator Impact During the Transition

Weekend
Its important to understand what will happen during the transition weekend in order
to effectively communicate to your users and business units what to expect during
the service transition. As this migration process begins, the experience within the
tenant will be impacted while users are transitioned between services.
During the transition weekend, email flow will be uninterrupted and incoming
mail will not be lost.
Users who are working in Outlook during the transition will see a message
saying that Outlook needs to restart. There may be a period of up to two hours
(worst case scenario) after the issuance of this message where Outlook cannot
connect to the new service. This is due to the time it takes to clear various
connection caches in the service. If this temporary state is impacting a user
who needs to process email, access to email in the new services will be always
possible using Outlook Web App (and by ActiveSync devices if they have been

re-configured post transition (see below)). After transition, by default Outlook
Web App and ActiveSync are set to On for every user, regardless of your
BPOSS prior settings for these features.
The BPOS-S version of Outlook Web App will stop working over the course of
the transition weekend, and users will get a Disconnected message. At that
time users can immediately reconnect to the service with Outlook Web App
using the Office 365 URL. Information on where to find what URL should be
published to your users in advance as part of your communications plan. (See
Appendix B, Transition URLs, Ports and IP Addresses for Office 365). If your
users try to use the old Outlook Web App URL, they will be redirected, but it will
be a smoother experience for your users if you have communicated the new
URL in advance.
Mobile device access (via Active Sync) will need to be reconfigured with the
appropriate Office 365 settings, because the mailbox has transitioned to the
Office 365 tenant as part of the process. Information on where to obtain the
steps to setup your mobile device in Mobile Devices in Section 3.
SharePoint site collections will be locked in a read-only state for the transition
weekend to allow the final synchronization of data between SharePoint in the
BPOS and Office 365 environments. There are also two short periods of
SharePoint downtime: the first for final data replication occurs a week prior to
the transition weekend to start the cutover to the new service, and the second
occurs a week after the transition to complete the cut over. Both downtimes are
scheduled during a weekend in order to minimize user impacts, and both are
very short.
Instant Messaging and Live Meeting services will continue to function during
the transition weekend.
For email, all users do not transition at the same moment: there will be a rolling
change to service to email users over the course of the transition weekend. Microsoft
cant predict the order of mailbox transition or schedule individual mailbox transition
in a specific order. Particular care should be given to communicate with your
international users regarding the timing of transition. For example if you have a
tenant in Microsofts EMEA region or Asia region but with users in the USA, the
transition will start for your tenant before your USA based users start work on the
Friday of transition (depending on their exact time zone). You should also plan for such
impacts with your help desk.
For SharePoint, transition occurs at exactly the same time for all users. SharePoint is
read-only for everyone during transition, and then is restored to normal function for
everyone at the same time post-transition.
Tenant administrators can expect the following impacts to the service during the
transition:
The Microsoft Online Admin Center will become read-only in the 24 hours prior
to the transition of service.
o Subscriptions and licenses cant be added, modified or deleted or
redistributed during the transition.
o Users cant be created, modified or deleted starting when the Microsoft
Online Admin Center becomes read-only, and throughout the transition

weekend. However you will be able to make changes to the password for
existing users if you need to. This may be necessary if a user has
forgotten their password, or if you need to deny service to a user for
urgent Human Resources reasons. Passwords changed in this timeframe
will also be synchronized to the new Office 365 service, so that when this
user tries to access Office 365 after transition they are granted access or
denied as per your intent.
o Once transition completes, the BPOSS Microsoft Online Admin Center
will become unavailable for all your administrators and all administration
will need to be done using the Office 365 portal.
Transition Support
Before starting your BPOS to Office 365 transition project, you should become familiar
with the support options that are available to help you resolve issues that may arise
during the transition. Microsoft has established a support team dedicated to providing
assistance with any transition issues that arise. To contact this support team, see
Contact Technical Support for Microsoft Online Services, at
http://g.microsoftonline.com/0rmcm00en-us/5022.
In addition to planning for transition support from Microsoft, you should work on
developing a plan to manage issues arising within your own organization specifically
related to transition activities. This might be a temporary team dedicated to transition
activities in your existing help desk, or a separate team entirely. You should have an
established a set of contacts and escalation paths within your organization for the
transition process to coordinate and communicate your activities relating to the
transition in order to address any issues as a result of the transition.
In planning for the support integration between your organization and Microsofts help
desk, you should take into consideration the following suggestions:
Limit the interactions between your support organization and Microsoft to a few
key individuals. This will provide a consistent message between your
organization and Microsoft; ensuring calls are monitored and progressed
appropriately, without a duplication of effort. Your users should never call
Microsoft support we cant act on their requests, and the work with Microsoft
should be a technical peer-to-peer dialog.
Document and track any issues as they arise, and develop and approach to
systematically resolve them and track their resolution to completion. Most
issues will be predictable impacts described in this document which you should
plan to resolve locally, and which you can reduce with advance user
communications planning.
Consider executive users and their assistants, and international users. These
and other classes of VIP or business-critical users might need special support
processes.
Customer Responsibilities
Customers transitioning from BPOS to Office 365 are required to assume specific
responsibilities in the transition process. Understanding these responsibilities at the
start of the pre-transition phase is critical to achieving a successful transition and

usage of the Office 365 service. The high level responsibilities are listed here, and
later in this section, the same tasks are presented in timeline order.
Although there is no data and almost no server software to be migrated by you during
this transition, you are nonetheless adopting new client and server software for
enterprise use. The deployment of this software should be managed and tested using
your existing processes for new software deployments.
Key tasks/responsibilities for organizations that are transitioning from BPOSS to
Office 365 include:
Assign a project manager. Your organization must assign a person to
manage your BPOSS to Office 365 transition project and lead your transition
team. Its critical to coordinate the transition activities through a central owner,
as there are a number of parallel activities and coordination across these are
required in order for the customer to be successful in their transition.
Develop a project plan. Your transition project plan is used to schedule and
track progress for the BPOSS to Office 365 transition work streams. The plan
should include a transition schedule that shows when each transition milestone
will be reached. A project plan is an essential part of the requirements for a
successful transition, as the multiple processes and technical work streams
overlap and require coordination in order to ensure that the transition proceeds
smoothly.
Develop a transition plan based on technical requirements. The project
teams technical activities should provide for the resolution of possible business
and technical impacts in a customer BPOSS environment that would prevent
the usage of the Office 365 service. The plan should provide a method for
testing of any implementation items that have multiple dependencies within
the Office 365 suite. A BPOS to Office 365 Transition Checklist can be found at
http://www.microsoft.com/online/help/en-us/helphowto/8939e90a-59dc-4f0f-
aec0-19a899c0af75.htm.
Document your tenant. Microsoft recommends that part of your operations
strategy for managing the online service is to have up-to-date configuration
documentation for all aspects of your BPOSS (and ultimately Office 365)
service. Documentation should include not just the documentation of the
service offering from Microsoft, but also the customizations that are a key
element of the end-to-end service offered to your end users. This
documentation will help with this transition and future change management.
Install and configure the Directory Synchronization Tool. In BPOSS, the
Microsoft Online Services Directory Synchronization Tool (DirSync) can be used
to keep your local Active Directory environment synchronized with your BPOSS
directory. To restore service functionality and operate in a fully Microsoft-
supported status, if you are currently using the Directory Synchronization Tool
for BPOSS, after transition to Office 365, you are required to deploy the
Directory Synchronization Tool for Office 365. If you are not currently using
DirSync, then there is no need to start doing so for transition or post transition
in Office 365. For more information in Active Directory requirements, see
Deploy Directory Synchronization for Office 365 Post Transition in Section 3.

Ensure that each end-user workstation meets Office 365 client
requirements. Each end-user PC must meet the Office 365 client
requirements, which have changed since the introduction of BPOSS. To
download the current Office 365 requirements, see
http://www.microsoft.com/en-us/office365/system-
requirements.aspx#fbid=ar65A2Nz-YZ.
Plan and coordinate end-user support. Before transitioning, you must plan
for support of your BPOS users. This includes planning for escalation of support
issues to Microsoft via a limited number of contacts in your organization. There
are three main areas to look at when planning for help desk impact, and how it
will ultimately affect your business. They are:
o Support for transition preparation and the transition weekend.
Plan to support and communicate with your users during the course of
the actual transition when the services are transitioning between BPOSS
and Office 365. If your communications plan provides end-user guidance
for transition tasks, your help desk should be ready to support end users
through these activities. However Microsoft recommends avoiding
assigning technical tasks to end users when at all possible.
o Day 0 support. This is primarily about allocating additional staff to
support any issues that are a direct result of the transition, allowing your
help desk to deal with both standard support issues and transition
related support issues. You might also temporarily adjust the dial plan
sequence of your help desk phone system to mention transition and
provide a minimum key stroke path to the right help. For big end-user
changes, some companies establish day 0 white glove support for VIPs
or on-site drop-in support kiosks for help with local issues. The amount of
time and resource you invest in day 0 support for your users is for you to
judge based on the degree of change you are introducing, the budget
and resources available and the extent to which you want to invest to
minimize disruption in your environment.
o Office 365 support. In parallel with the above, your support
organization should also be focused on internal changes necessary to
support Office 365. Your support processes and support content should
be fully documented and updated to support Office 365, your help desk
staff should be trained in advance and any systems or tooling they use
updated.
Plan, develop and execute training plans. You will need to implement
training for your end users, service administrators (email and SharePoint) and
your help desk staff, addressing changes in the service between BPOSS and
Office 365.
Plan, develop and execute transition communication plans. In addition
to providing training and communications plans for your help desk, you will
need to inform end users about the transition to Office 365 service offerings
and what, if anything is required of them.
Test and validate service customizations. In order to ensure you have a
smooth transition experience, and to avoid service interruptions post-transition,
its important to document and understand all customizations that have been

put in place for BPOSS, and ensure they transition and operate as expected.
The creation of a testing plan and associated remediation activities will help to
identify problem areas after transition, and provide a guide for your testing
processes. Every point of IT integration and customization with the BPOSS
service should be validated in advance for Office 365 and confirmed as
functional after the transition.
Test and validate network access. While some network ports and firewall
configurations remain the same between BPOSS and Office 365, a number of
networking changes are required and these should be validated and tested
prior to the transition weekend. The port and network settings provided in the
document are provided for implementation early in your transition project. The
amount of work required for the validation and remediation of your network is
directly correlated to the degree of customization you have implemented in
support of BPOSS.
Test and validate email flow and message hygiene solutions. Testing of
email flow and message hygiene is critical to ensure the continued operation of
the service during and after the transition weekend. While Microsoft has worked
hard to ensure email flow continues without impact during the transition,
customers are responsible to ensure their end-to-end email flow and hygiene
solutions have been updated and tested for interoperability and
communications with the Office 365 environment. The creation of a testing plan
and associated remediation plan will help to identify problem areas, and
provide a guide for your transition testing processes.
Document FOPE customizations and SRs. As part of the design intent for
transition, the Forefront Online Protection for Exchange (FOPE) service used in
BPOSS will transition intact to Office 365. Note that in BPOSS, all FOPE
configuration changes were implemented via a call to customer support
(Service Request (SR)). In Office 365, all FOPE changes are via the self-service
administrator portal. Its important to understand what changes to FOPE were
implemented in BPOSS, and as part of your post-transition process, validate
those changes are in place and functional.
Review and adjust the end-to-end provisioning process. Most enterprise
customers provision their BPOSS accounts based on automated processes that
feed from various identity systems, and synchronize with BPOSS via Active
Directory. Microsoft recommends that you review and update all your
provisioning processes such as adding or deleting users, modifying user
objects, changing user names and resetting passwords, to ensure you have
procedures that will work with Office 365.
Test and validate SharePoint content. As part of this transition process,
your SharePoint environment will be transitioned to SharePoint 2010. The
testing and planned remediation (if required) of SharePoint content, sites and
site collections for Office 365 is recommended to ensure proper presentation of
content post-transition. For information about differences between the BPOS
and Microsoft Office 365 versions of SharePoint Online, see SharePoint Version
Differences in Section 3.
Plan for mobile devices. As part of the transition, RIM Corporation is taking
ownership of the Blackberry Enterprise Service hosting for Blackberry devices.

Microsoft recommends that you work with RIM to understand their service, and
plan for any changes required for Blackberry devices to consume the Office 365
service. For non-Blackberry mobile devices, your end users will be required to
make changes to the configuration settings of the device post transition. Your
end user communication plan should include guidance on what activities are
required, and when. For more information, see Blackberry (RIM) Devices in
Section 3.
Plan for administrator roles and licenses after transition. Many
customers do not have a license assigned to their Administrator user account in
the BPOSS service, because this was not required. Office 365 requires that
your administrator has a valid license within the Office 365 service. Compared
to BPOSS, Office 365 provides organizations with additional granularity to the
administrator roles, providing options to meet your security requirements for
administrators with reduced risk or exposure.
Train legal users and identify users who have permission to do
discovery searches. Your legal users should understand the changes in the
interface for discovery between BPOSS and Office 365. In Office 365, you can
also use PowerShell scripts to perform more sophisticated searches against
your environment.
Develop standard PowerShell scripting. Office 365 extends the ability to
provide additional configurations to the Office 365 service via the Remote
PowerShell interface. Microsoft recommends training your administrators and
help desk and operations staff in how to use PowerShell. In order to develop a
consistent and repeatable approach to managing your environment, consider
developing a standard set of scripts for common tasks.
Complete post-transition tasks. Even if your organization is not planning on
adopting new features in the Office 365 service, there are various technical
confirmation and validation tasks Microsoft recommends to be performed post-
transition in order to achieve equivalent functionality with the BPOSS Service.
(E.g. shared mailbox migration, records management policies, outlook rules,
transition reoccurring meetings from Live Meeting to Lync Online, etc.) For more
information, see Post-Transition in Section 2.
In addition to the activities above, its critical that all technical contact details in the
current service are up to date and accurate. It is your responsibility to make sure that
the contact details for the Account Owner and Service Administrator are updated in
the Microsoft Online Services Customer Portal. Microsoft will send multiple email
communications before, during, and after your transition to provide the information
that you need throughout the process. These points of contact will be sent to all
registered administrators. Ideally you should make sure at least one administrator has
a registered email address which does not depend on the functioning of the BPOSS
tenant so that you will still receive messages in any unforeseen tenant outage
situation.
To update administrator contact details, sign in to the Microsoft Online Services
Customer Portal.
On the Subscriptions page, locate the subscription that you want to update.
In the Actions list, select Edit service details, and then click Go.

For general information about transition, visit the Microsoft Office 365 transition
center website, at http://go.microsoft.com/fwlink/?LinkId=210626.
Transition Phases and Milestones

The following diagram shows the phases and high level milestones for organizations
transitioning from BPOSS to Office 365, starting when Microsoft notifies you that you
have 60 days until transition. Your end-to-end project may need to start much sooner
than the first communication from Microsoft, depending on the customizations and
testing required.
At each milestone in the transition process, you should ensure you have completed all
the preceding tasks before marking the associated milestones complete.

Diagram 1: BPOSS to Office 365 transition timeline: Microsoft and Customer work streams

BPOS Pre-Transition Phase
With any enterprise service, there are a number of dependencies, line-of-business
processes, and end users, all of which rely on the availability of the service to
enable them to function. Changes to these IT services have the potential to impact
service to your users and customers.
The pre-transition phase requires the most work on your part, as it impacts most if
not all IT service processes and services. The changes required during this phase
will place additional demands on all aspects of the IT organization, including
desktop client configuration, change management activities, service provisioning,
networking and end-user communication planning.
During this pre-transition phase, while you are engaged in the above tasks,
Microsoft Online engineering sets up your target Office 365 tenant and migrates a
copy of your content and settings. Under normal circumstances, these Microsoft
tasks are invisible to you, but if there are any problems, or if your input is needed,
Microsoft will contact your administrator by email.
By the time this phase is completed, a majority of your prerequisite work will have
been completed. The endpoint of this phase is when the transition starts and your
users are moved to Office 365 over the course of the scheduled transition weekend.
In Diagram 1, the pre-transition phase is indicated with blue milestone markers.
Pre-Transition Phase Key Activities

The following are the key transition tasks and events that you carry out in the pre-
transition phase:
Update technical contact information. The interactions between your
BPOS administrators and Microsoft will happen via email, so it is critical to
review and ensure the appropriate technical contact information in the BPOS
S administration portal has been updated to ensure receipt of transition
communications. It has been common practice for customers to provide an
unmonitored email address as a contact address for tenant administrators in
the BPOSS portal, and this will result in missing essential communications.
Validate and document your current configuration in BPOS. Though
the automated transition process is designed to validate and migrate all
service configuration settings during the transition, its still important for you
to document and understand your environments integration with the BPOSS
service. This gives you a reference to use against the post-transition
environment to confirm no loss of service functionality.
Let your Microsoft representative know when you want the
automated transition to occur. While Microsoft will make every attempt to
deliver against the requested timeframes, scheduling cannot be guaranteed.
Microsoft is moving users, data, site collections and settings during the
transition, and the schedule is organized by Microsoft to make sure that all
transitions scheduled for a given period can completed in the designated
period and do not impact the production BPOSS system for the subscribers
who remain on the BPOSS system.
Validate the current state of your Active Directory. There are several
Active Directory items to verify prior to migration to ensure a successful

transition, including ensuring that no distribution groups have a DisplayName
property that has not been populated. Rather than verify each of these
manually, or even with separate scripts, the easiest way to complete this
verification is to run the Deployment Readiness Tool. Resolve any issues that
the Deployment Readiness Tool identifies at least 2 week prior (T-14) to your
transition date.
Review the differences between attributes synched in Active
Directory BPOS and Office 365
There is a significant difference between the BPOS and Office 365 Active
Directories in terms of the attributes synced in both. The article
http://support.microsoft.com/kb/2256198 depicts the differences between the
two. These should be verified in order to ensure that the state of the Active
Directory meets best practices prior to transition. In addition the Deployment
Readiness Tool should be run in order to iron out errors and issues prior to
transition.
Validate the configuration of Directory Synchronization Tool for
BPOSS and continue to perform synchronization. Directory
synchronization enables you to synchronize objects from your Active
Directory to the BPOSS environment. There is an updated version of the
Directory Synchronization Tool for Office 365, and the BPOSS version of the
Directory Synchronization Tool for BPOSS will not work with Office 365. The
BPOSS synchronization will continue to work up until the start of the
transition weekend. Microsoft recommends scheduling for the suspension of
all technical and business identity change processes, including directory
synchronization, approximately 12 hours before the start of the Transition
Window. However you choose to manage your organizations identity
processes during transition, it is a requirement that directory synchronization
is suspended 12 hours before the transition begins.
Upon completion of the transition process, the Office 365 portal will not
permit changes to user properties because the tenant is not yet authoritative
for the user directory. Becoming authoritative can take between 24 and 72
hours (worst case) after transition completes. When you see that you can
make changes to user attributes via the Office 365 tenant portal (not the
BPOSS Microsoft Online Admin Center which will be unavailable after
transition), then your tenant has directory authority and you can re-establish
directory synchronization with the Office 365 environment using the Office
365 version of the Directory Synchronization Tool. For more information about
key work items you must complete before you start the Office 365 Directory
Synchronization Tool, see Deploy Directory Synchronization Tool for Office 365
Post Transition in Section 3.
If you were using DirSync before the transition, you are required to continue
to use the Directory Synchronization Tool in Office 365.
Deploy Lync Online client. Prepare and deploy the Lync Online client for
use by your users during the pre and post-transition phases . In order to
successfully consume the changes in Lync, we recommend that you plan and
address the requirements for deployment of the client portions well in

advance of the anticipated transition weekend in order to reduce the impact
on your users of multiple simultaneous changes. The deployment and
transition work to the Microsoft Lync client is described in more detail in Lync
Deployment in Section 3.
Prepare for Office 365 SharePoint Online. SharePoint Site and Site
Collection Administrators are recommended to reference the SharePoint
Online 365 Developers Guide, so that you can understand what types of
custom solutions are available in the services. To download the Developers
Guide, go to http://www.microsoft.com/download/en/details.aspx?id=17069.
You should also plan for changes in how your users current access SharePoint
sites in BPOSS through the Microsoft Online Services Sign In client
application, as the URLs presented in that location will no longer be
presented in that client post-transition. You could use Active Directory group
policy to push URLS to the workstation SharePoint Sites profile setting or to
browser favorites. Post transition, Microsoft will provide each user a list of the
sites they have access to in the SharePoint Online Team Site.
Deploy client applications and the Office 365 desktop setup. The
successful usage of the Office 365 service requires that supported rich client
Office applications (e.g., Microsoft Outlook 2010) are deployed and installed
on users PCs if rich clients are intended to be used. The Office 365 desktop
setup is deployed to ensure that client applications are properly updated and
configured for Office 365.
Finish mail migrations or prepare plan for completing migrations
after transition. If you are still migrating from an on-premises messaging
platform, the user mailbox migrations will need to be completed before, or
suspended until after the transition to Office 365 has completed. As long as
there is no impact to your transition project, you can continue migrations
until the T-14 milestone. Its strongly recommended to finish any user mailbox
migrations in advance of the transition. Otherwise you will be required to
recreate your migration infrastructure after the transition to allow the
completion of migrations into Office 365 to continue. If you have users still
using on-premises email services at the time that you planned to move to
Microsoft Online, you might consider postponing that mail migration until you
are running natively in Office 365, to avoid the need to build two migration
solutions and to reduce impact on your IT department of running concurrent
user-facing projects. Your decision on timing of mail migrations will need to
consider the business needs combined with your IT resourcing and other
constrains that might impact concurrent IT projects (e.g. any business critical
change freeze periods).
Review any planned changes for your BPOSS tenant. If any services
are planned to be added to your existing BPOSS tenancy, Microsoft
recommends planning your adoption strategy to postpone these extensions
of service until after the transition has completed in order to reduce the
complexity of the transition. For example:
If you havent started SharePoint deployment, it might be prudent to plan
to do so after the transition has completed.
If you have not started journaling or archiving at this time, it would be
simpler, given the imminent transition work required, to implement this
directly in Office 365.

If you have not yet adopted web conferencing in your organization, it will
be less disruptive to users and simpler for IT to do so directly in Lync
Online after transition to Office 365.
From an IT change management perspective, at this point in the lifecycle of
BPOSS, the adoption of service functionality directly into Office 365 provides
the least complex route for service adoption, avoiding the need to
concurrently execute transition readiness work alongside new service
adoption projects.
Prepare users. You will be making significant changes to the user
environment as part of this transition. Your users are impacted by both the
change to the service and changes to your processes that accompany the
service (e.g. password reset procedure, new employee training). You must
prepare your users for this change using your service roll out and user
communication procedures.
Prepare help desk. Your help desk must be trained to support Office 365
service offerings. In addition to providing standard transition support,
Microsoft recommends that you plan to have additional resources available to
ensure you can address the needs of transitioned users in additional to the
standard help desk calls. (e.g. VIP services for management and critical
personnel).
Office 365 Transition Phase

The Office 365 Transition phase includes the activities and work streams that take
place during the transition weekend.
In Diagram 1, this phase is indicated with red milestone markers.
Users can expect the following impacts to the service during the transition phase:
During the transition weekend, email flow will work uninterrupted. To reduce risk
to the maximum extent possible, you might decide to prevent some or all of your
users from consuming the service over the course of the transition weekend, but
this is not required by Microsoft. Whatever change management strategy you
employ, email from external senders will continue to be delivered to Microsoft
Online, and will be available whenever you decide to let users on to the service.
The decision as to whether to close down access to the email during the
transition weekend is yours, and depends on various factor including:
Your business users ability to function while email is unavailable.
The degree of customization today in BPOSS around identity, email
flow and network access.
The degree of post-transition testing and validation you want to
perform before letting users access your messaging service.
The degree of post-transition configuration and customization you want
to implement before letting users access your messaging service.
Any requirement you have to confirm that a compliance archive is
intact and is still capturing mail and changes, before letting users
conduct business on the service.

SharePoint site collections will be locked into a Read Only state (which means
you will not be able to post new content, or adjust content that is already there)
for the transition weekend to allow the final synchronization of data between
SharePoint in BPOS and Office 365 environment. There are two very short
periods of SharePoint downtime: the first for final data replication 7 days before
the transition weekend, and the second 7 days after the transition weekend to
complete the cutover to the new service. These are scheduled on weekends to
minimize user impact.
Instant Messaging and Live Meeting services will continue to function during the
transition weekend. As with email, to carefully manage change in your
environment, you might decide to make these services temporarily unavailable
or avoid critical web conferences during the transition weekend. However, this is
not a technical requirement by Microsoft.
Office 365 Transition Phase Key Activities

The following are the key deployment tasks and events that you carry out in the
transition phase:
Issue a what to expect this weekend communications to end users.
Prior to the start of the transition weekend, send all users the necessary
notifications and instructions they need to make the transition to the new
hosted services platform.
Update DNS records. As a prerequisite for transition, update your DNS
records (for example, CNAME and SRV records) to at your domain registrar.
Monitor email for transition end. Administrators monitor their contact
email for transition end or other messages from Microsoft.
Support users. Provide support for all users who will see the impact of
transition throughout the weekend, in all time zones where users are working.
Office 365 Post-Transition Phase

Once the transition has been completed, Microsofts engineering work stream is
complete; you should now complete your final validation of services. This is defined
as the post-transition phase.
In Diagram 1, this phase is indicated with green milestone markers.
Post-Transition Phase Key Activities

The following are the key tasks and events that you carry out in the post-transition
phase:
Validate the transition to Office 365. While the transition process is
designed to validate and migrate all essential configuration settings during
the transition, not all settings will transition as is from one tenant to the
other. Please review this document to ensure you have a full understanding of
the settings that will and will not transition across. You should have created a
document listing all of your settings in order to provide a robust checklist to
use against the post-transition environment to ensure no loss of service
fidelity and functionality.
Validate messaging configuration. Once transition has completed,
validate the ability to access the mailboxes, and ensure full send and receive

functionality. This is to ensure successful access to transitioned mailboxes,
and the ability to send and receive mail from both the client configuration, as
well as mobile devices associated with the mailbox.
Validate Free/Busy and Out of Office Status. Ensure that the Free/Busy
status is set correctly for your organizations users. Additionally, verify that
users Out of Office messages and status are shown as expected, and that
users can change their status and Out of Office messages as expected.
Reconfigure and validate mobile phones and devices for Office 365.
Set up user mobile phones to access your email using the Exchange
ActiveSync protocol, and validate the application of ActiveSync policies from
the BPOS environment. For more detailed information, and up to date
information on connecting mobile devices to the service, review the
documents at: http://technet.microsoft.com/en-us/library/cc742556.aspx.
Perform post-transition service testing. After transitions are
completed, perform full-scale testing of Office 365 service functionality
according to your test plans.
Install and validate the Office 365 Directory Synchronization Tool.
Directory synchronization enables you provision user accounts from your
active directory, and will continue to work until the transition weekend. Upon
completion of the transition process, you will be required to download and re-
establish directory synchronization with the Office 3655 environment. For
more information, see Directory Synchronization in Section 3.

Detailed Transition Timeline
The remainder of Section 2 provides a detailed list of activities that must take place
during the various phases of the transition timeline so that you can properly prepare
for the transition. The transition plan as presented in this document is sequenced by
the required engineering milestones leading up to, and through transition. Since the
transition will be scheduled at different times for different customers, there are no
specific dates included in this guidance; all the outcomes of every pre-transition
work stream must be achieved by 14 days before transition start (T-14 milestone) to
ensure the transition can proceed without problems or interruption of service.
Please note that Microsoft has communicated that all transitions will be completed
by the end of September 2012 and that customers will be added to the transition
pipeline between now and that date.
The timeline provided in this document is intended as a starting point for formation
of your overall transition approach. Its expected that your overall service transition
project will be well under way and partially complete by the time you receive initial
communications from Microsoft on a likely transition date (T-60 milestone).
(Earlier than T-60 Days) to Transition

The timing of when work on this milestone starts is for you to designate. Given the
September 2012 deadline for transition of BPOSS to Office 365, all customers
should already be planning and conducting the work outlined in this section.
General Activities
Review the Office 365 Service Descriptions and decide to move ahead with
transition. The assumption for this document is that you are planning on
transitioning to Office 365. If you have any concerns about the viability of
Office 365 for your business, please urgently contact your Microsoft
representative.
Use an Office 365 tenant with a trial subscription to fully evaluate the Office
365 services.
Conduct an inventory and assessment of the Microsoft Office Suite in your
environment, and upgrade client software as necessary. With BPOSS, there is
no prescribed earliest timeline for moving off Office 2003, (with the exception
of Lync 2010 which is covered below), and you are encouraged to move at
the earliest possible time to reduce readiness risk that could impact your
transition.
Conduct a business process review for impacts as a result of service
transitioning, and identify business processes that require or depend on the
BPOSS Service. (eDiscovery, provisioning, help desk, SMTP Relay and line-of-
business applications, etc.)
Start to document your current infrastructure and application environment,
and begin the process of evaluating and planning to implement the routing
and firewall changes required for Office 365. The required routing and firewall
changes can be found in Appendix B: Transition URLs, Ports and IP Addresses
for Office 365. You will be able to confirm the requirements in your
environment and test them as you implement them using an Office 365
tenant with a trial subscription.

Prepare your communications plan for the remainder of the project, to be
reviewed, approved, funded and executed within your organization.
Prepare infrastructure and Use Case/Test plans, and begin infrastructure and
initial testing.
Plan for password synchronization and password change approach for T-60 to
T-7. For more information, see Required Password Changes in Section 3.
Document current eDiscovery processes, journaling rules, and configuration
information and prepare for any necessitated changes.
As part of the communications plan, prepare for communicating to and
training all users and administrators on the use of credentials in the Office
365 suite.
Document your messaging hygiene solution, data loss prevention solution
(DLP), inbound/outbound email flow, on-premises mail inspection, etc., for
implementation and inclusion as part of the Office 365 configuration.
Review all customer requested changes within BPOSS that have been
implemented via a Service Request (SR) to support. A review of the SRs filed
will allow appropriate planning to remediate Office 365 via self-service
mechanisms in the service, should any BPOSS customized items fail to
transition. If you need help with this item, contact your Microsoft TAM. For
more information, see in SR Review in Section 3.
Lync Activities
Inventory current use of Live Meeting in your environment, and determine
users, teams and business processes that will be affected by transition into
Lync Online. Even though Live Meeting can be consumed after the transition,
customers should plan for the discontinuation of the Live Meeting service.
Plan for the extraction of any valued recorded content from Live Meeting.
Develop your strategy for switching your users to Microsoft Lync 2010 from
Live Meeting.
Develop a training and communications plan for Microsoft Lync 2010 from
Microsoft Office Communicator.
Review all client-side customizations for the Office Communicator Client in
preparation for the transition to Lync. (E.g. client plug-ins such as CUCiMOC,
WebEx, etc.). As part of your process, you will need to obtain the updated
products from their vendors for the customized components, and test in
advance to ensure a successful integration with Lync Client during the
Upgrade to the Lync Client from the Office Communicator Client. An Office
365 trial tenant is ideal to perform this type of testing.
Update existing Windows Operating System Images/Deployment Packages to
reflect inclusion of Lync Client, with any custom client-side plug-ins.
Depending on your deployment schedule, you might not be releasing these
packages for installation at this time.
SharePoint Activities
Evaluate the potential SharePoint content impacts as a result of the transition
to SharePoint 2010/Office 365. (Upgrading your testing environment, code
validation, customizations, Web Parts and overall functional testing of
content)
Develop a training and communications plan to introduce SharePoint
functionality changes and additional features, functions and services,

including URL changes, UI upgrades, enterprise features, functions, services,
My Sites, etc.
Develop training and communications for SharePoint site administrators
about the SharePoint Online 2007 (BPOSS) and SharePoint Online 2010
(Office 365) user interface (UI) upgrade post-transition. (Also known as the
SharePoint Visual Upgrade.)
Review existing SharePoint site collections and clean up any content and sites
that are no longer needed. This is not required, but it is a great time to
confirm and document your use of SharePoint. Note the tenant size
considerations in the Microsoft SharePoint Online for Enterprises Service
Description, at http://www.microsoft.com/download/en/details.aspx?
id=13602.
Document BPOSS SharePoint sites and collections; specifically focused on
collecting existing URLs that are published in the Microsoft Online Services
Sign In client application. After transition to Office 365, these links will no
longer be presented to end users on the workstation, which may lead to an
interruption of business processes. You will need to develop an
implementation and communication plan to update your URLs as required for
the post-Office 365 environment. (e.g., Leveraging Group Policy to push out
URLs to the client environment, and documenting the URLs in a central
location. Microsoft will create a personalized SharePoint landing page for each
user in the main Team Site that lists the URLs for sites the user can access.
Messaging Activities
Develop a training and communications plan for transition from
Outlook/Office 2003 to Outlook/Office 2007/2010 depending on your
requirements.
Develop a training and communications plan for using Outlook Web App in
the Office 365 messaging environment. This is particularly needed if your
intent is to use the Microsoft Office Professional Plus subscription of Office
365. There is no way to buy, deploy and use this version of Microsoft Office in
advance of transition to Office 365, so until you can acquire and deploy Office
Professional Plus, your email users will have to use Outlook Web App for their
email. It is likely it will take you many business days after transition to
acquire, package and deploy Office Professional Plus.
Document mobile device (ActiveSync or Blackberry (BES) Policies) and
connection settings, as connection settings will change post-transition. If you
dont currently have an inventory of mobile devices in your organization, you
will need to capture and inventory of current mobile devices and users. After
transition to Office 365, ActiveSync services will be enabled by default for all
users, regardless of your previous settings, but server names will have
changed, requiring a reconfiguration of the mobile device. For more
information on reconfiguration of mobile devices, see Mobile Devices in
Section 3.
(T-60 Days) to Transition

The T-60 milestone event is started when you receive communication from Microsoft
indicating your planned transition date is approximately 60 days away. You will not
get an exact date at this time. Depending on circumstances, this may be the first
point of contact between you and Microsoft Online Services regarding your

transition. As before, compare the timeline for transition as communicated to you
by Microsoft with the work indicated as necessary in this section, and modify your
transition plan accordingly.
General Activities
Conduct Online Services training for the help desk team to equip them for
supporting the usage, troubleshooting and administration of online services:
Administration and Troubleshooting: Enterprise Online help:
http://onlinehelp.microsoft.com/en-us/Office365-enterprises
Develop and distribute the communications for the identity outage over the
transition weekend to HR, help desk and administrators.
Update your customer password expiration/change policy to coordinate
password changes for the admin and all users during the next 60 days to
ensure synchronization with both BPOSS and Office 365 environment(s). For
more information about these required password changes, see Required
Password Changes in Section 3.
Finish your proof of concept (POC), pilot and deployment of Office 365
Desktop Setup utility, after validating this tool and the changes it makes will
co-exist safely in your current workstation environment.
Review workstation software deployment log(s) for Office 365 prerequisites
and update deployment strategy as needed. The location and nature of these
deployment logs will vary depending on what enterprise
packaging/deployment solution is being used to distribute updates to the
desktop. The goal is to ensure desktop deployment of latest software
packages is proceeding according to plan.
Provide implementation and notification plans to networking team(s) for DNS
record changes, port/protocol changes, online URLs and namespaces, etc.
Document and validate required record changes. The updated ports and URLs
for Office 365 can be found in Appendix B, Transition URLs, Ports and IP
Addresses for Office 365.
Lync Activities
Change DNS records for Lync. You will need to add additional SRV and CNAME
records to support the deployment of Lync both before the transition
weekend, and as part of the planned rollout of the Lync 2010 Client. These
records are to be created in addition to the existing BPOSS records for the
Office Communicator client, so there should be no expected service impact.
Type Service Protoc Por Weig Priori TT Name Target

ol t ht ty L
SRV _sip _tls 443 1 100 1 Hr your sipdir.online.lync.co
domain m
SRV _sipfederatio _tcp 506 1 100 1 Hr your sipfed.online.lync.c
ntls 1 domain om
CNAM sip.your sipdir.online.lync.co
E domain m

Begin the client roll out of the Lync 2010 client package. Do not attempt to
switch your users to the Lync 2010 client if you have not yet received
communications from Microsoft, as the Lync 2010 Client will not work with
BPOSS until you are in Microsofts pipeline for transition to Office 365 as
indicated by the 60 day Be Ready By communication.
Schedule implementation dates for additional firewall and port assignments

for services transitioning from BPOS to Office 365 (For T-14 Connectivity
Pilot). Required firewall and port assignments can be found in Appendix B,
Transition URLs, Ports and IP Addresses for Office 365. The intent is to add the
additional ports and functional requirements without impacting the current
BPOSS environment.
Validate that SharePoint Online and on-premises line-of-business applications
(e.g. applications that are either integrated with SharePoint, or rely on
SharePoint as part of their business processes) have been tested against an
Office 365 trial tenant. The primary goal of the validation process is to ensure
that your SharePoint applications will function properly to support the
business once moved to SharePoint Online in Office 365.

The T-30 milestone event is started when you receive additional communication
from Microsoft indicating your planned transition date is approximately 30 days
away. Depending on circumstances, this may be the first point of contact between
you and Microsoft Online regarding your transition; nevertheless, the tasks indicated
in this document for the milestones prior to this still need to be considered,
performed (selectively, depending on your circumstance and technical environment)
and completed as part of your transition plan.
General Activities
Identify help desk members identified for an Online Services SWAT team (or
for whatever approach to transition support that you have chosen), and
provide detailed training, troubleshooting and usage around the following
Office 365 services:
Lync Online
Network connectivity
SharePoint Online
Exchange Online
Login user experience (UX) post transition.
At Microsoft, the target Office 365 tenant is now configured and will be
running in parallel, synchronizing data leading to the transition weekend. This
will be invisible to you as a customer. However, from this point forward,
password changes (in fact, all identity metadata) in the BPOSS environment
are being captured and relayed to the Office 365 tenant you will eventually
transition to.
You should be well underway with packaging and deployment of required
components (internet browser, Office components, and operating system
patches). The goal is to be complete with the required software package
deployments in advance of the T-14 transition date. For more information, see
Software Deployment and Packaging in Section 3.
Your infrastructure change/remediation efforts described during previous
milestones are in the final phases of testing, and have been declared are
functionally complete.
Change DNS records .You will need to change your DNS autodiscover entries
for each BPOSS custom SMTP domain when using these custom SMTP
domains in Office 365 and/or on-premises, with the goal of being completed
no later than the T-14 milestone in the transition timeline. For more
information, see Update DNS Settings for Outlook in Section 3.
Lync Activities
Office Communicator to Lync client package deployment is underway.
Validate updated firewall and port assignments.
Validate updated firewall and port assignments.
End all migration activities from on-premises environment to BPOSS.

Validate and confirm of updated firewall and port assignments.
Finish the validation of the messaging hygiene structure identified in previous
phases (DLP, Smart Hosts, etc.) as part of the Office 365 connectivity testing
configuration work.

The T-14 milestone event occurs when you have received communication from
Microsoft with a confirmed transition date, typically 14 days in advance of the
scheduled transition.
Important: If you are unable to be ready by the scheduled date, you must
immediately contact Microsoft Online Support to postpone the scheduled transition,
as this is your last opportunity to do so.
General Activities
Remediation and packaging and deployment activities have been completed
for transition. All software requirements for Office 365 are met at this point.
Directory Synchronization Tool for Office 365 servers build out is complete
(but dormant until post-transition). This is only a required task if you were
currently using Directory Synchronization with BPOS S. The Directory
Synchronization Tool requires an MS SQL instance as described in the
Directory Synchronization deployment notes and this should also be
considered in your build out. If you are making a platform change from x86 to
x64, planning for the decommissioning of the x86 server should be
scheduled.
By continuing past the T-14 milestone, you have committed to the scheduled
transition date and there will be no further opportunities to cancel the
transition after this milestone date. You MUST inform Microsoft of any inability
on your part to be ready by the scheduled transition date before T-14
milestone is passed.
Lync Activities
The assumption by Microsoft at this time is that you have completed the
rollout of the Lync Client software. Users who have not have the Microsoft
Lync 2010 software deployed will be unable to use Lync Online post-
transition, because the Microsoft Office Communicator 2007 software does
not work with Office 365.
The T-14 milestone begins the start of the pre-transition SharePoint
engineering activities performed by Microsoft, which will introduce two short
service interruptions as your BPOSS SharePoint infrastructure is
synchronized to the new Office 365 tenant. These are scheduled out of hours
and during the weekend for your region and occur 7 days before and 7 days
after your transition.
The assumption by Microsoft at this time is that you have completed any
ongoing migration from on-premises email into the BPOSS Service (e.g. from
on-premises Exchange, Lotus Notes, or other messaging environment into

your BPOSS Exchange Online service). If you have not completed your
migration, you should now postpone any additional changes until after the
transition weekend.

General Activities
Your internal communication plan should include a final transition notification
to end users.
Your internal communication plan should include a final transition notification
to help desk and administrators about administrator access interruption to
the BPOSS service during transition weekend.
Final coordination with HR and help desk, and communication regarding:
Inability to access any BPOSS management options other than the
Microsoft Online Admin Center main page.
Inability to change/add/delete SharePoint content.
Inability to manage BPOS users, contacts or groups.
Reminders to users of the transitioning process over the weekend and
its possible impacts (e.g. Outlook Web App, Outlook and mobile
devices will stop functioning over the course of the transition
weekend).
Schedule change window to stop directory synchronization for BPOSS
services
Communicate downtime of directory synchronization processes for
BPOSS to IT Operations Staff and Identity Administrators.
Caution: To stop synchronization, use the Directory Synchronization
tool. Do not disable the Directory Synchronization tool in the
Administration Center. Disabling it will result in your organization being
reported as a non-synchronizing organization during the transition
process.
Note: The transition start and end times in the two milestones which follow are
based on the time in the most western time zone of the region your service is
hosted. For services hosted in North and South America, this is Pacific time. For
Europe, this is Dublin, Ireland time. For Asia, this is New Delhi, India time. You will
need to convert these times to your local times in your planning and staffing.
(T-0) Transition Start (Friday 3 pm local time in the

most western time zone for your region)
General Activities
To reduce the impact to your support organization and IT department during
the transition weekend, consider limiting service access to only essential
users until transition is complete. This is not a requirement but it may be
prudent depending on your situation and post-transition plans. Incoming
email flow to your organization will still be functional during the transition
process, and no incoming mail will be lost.
Monitor the transition status with Microsoft to obtain the transition complete
notification, and begin your post-transition activities.

(T-00) Transition Complete (No later than Monday 3
am local time in the most western time zone for
your region)
At the T-00 milestone, you will receive an email notifying you that transition is
complete. After receiving this email, you can begin any post-transition activities.
This will be the last transition communication you will receive from Microsoft
regarding the transition, other than any communications related to transition
support calls you have opened.
General Activities
You are notified that the Office 365 service transition is complete. By this
time, all your users have already been seeing notices that they need to
restart Microsoft Outlook or reconnect to Outlook Web App.
Admin access to the Office 365 portal is established and access to the
BPOSS Microsoft Online Admin Center is denied. Confirm all
administrators can access the Office 365 with known credentials.
PowerShell Access to Office 365 enabled. Validate script functionality
against the Office 365 environment.
Mailboxes are migrated and ready for use.
SharePoint site collections are moved and ready for use.
Lync Online is available for use.
Messaging transport rules and FOPE Allow/Deny lists are migrated and
ready for use.
Note: Administrators will be unable to manage or change user properties or

perform tasks that require the Office 365 service to be authoritative for the
directory. You will know that you are now authoritative for the directory when
you are able to make such changes (24 72 hours later). Until your tenant is
authoritative for the directory you will not be able to successfully run the
Directory Synchronization Tool to synchronize with on-premises Active
Directory. However there is other important testing and validation work to
perform at this time while you wait for this authority to be claimed by the
tenant.
Complete the export of appropriate publicDelegate attribute information to
later restore permissions to as they were in your BPOSS operational state.
This configuration data MUST be collected before you restart Directory
Synchronization or it will be lost. For more information, see Preserving the
Public Delegates in Section 3.
Implement your testing plan; including validating the online services
components, line-of-business applications and interfaces, and your points of
customization as ready for release to production in your environment.
Lync Activities
Perform Lync Online service testing, including collaboration and conferencing.
Perform SharePoint Online testing, including validating permissions and
access to site content, and rendering of content.

Validate access to all SharePoint Online URLs.
Validate and implement mobile device, ActiveSync, BES and Role-Based
Administration policies. You may decide to defer some of these to later
depending on their criticality to your operations and service requirements.
Your help desk is assisting users in reconnecting their mobile devices or
POP3/IMAP clients to the Office 365 service.
Validate the implementation of the Blackberry Business Cloud Services for
Office 365 has been configured as expected for your Office 365 tenant. Your
help desk may have to be ready to help your users to reconnect their RIM
devices.
Validate and verify email flow to/from Exchange Online; Perform Exchange
Online usage testing.
Help desk should be available to answer questions about Outlook Web App
URL and client connectivity questions post-transition.
Update notification mechanisms for any tasks you have prepared users to do
themselves.
(T+8:00 Hours) Post Transition (Approximately the

first business day after transition)
The T+8:00 hour milestone is the return to normal operations after completion of
the transition process. This and all further milestones in this document are not
communicated or controlled by Microsoft; it is for you to designate in your transition
plan when normal service operations should resume in your organization.
General Activities
Your help desk is configured in a Day 0 mode to handle increased calls as a
result of transition questions and issues. They may also be performing
services which are not usual services for your help desk. By now your help
desk staff have been fully trained in Office 365, and your help desk content is
updated. For new support cases, you are collecting information with
appropriate Office 365 content keyword tagging in your support case
management solution.
Essential transition testing is completed, and, if service access was restricted
for certain users during transition, it is now allowed and restored for all end
users.
Business process testing starts. Also, you may now be confirming that
dependent line of business applications are functioning normally with the
Office 365 service. This process may continue for a while depending on the
number of technical dependencies.
(T+72:00 Hours) Post Transition

General Activities
Decommission of the Directory Synchronization Tool for the BPOSS server
and activation of the Directory Synchronization Tool for the Office 365
servers.

o Office 365 services and records are validated and directory
synchronization for Office 365 services can begin. The timeline for the
completion of your Active Directory synchronization to Office 365
depends on the number of objects and your available network
connection to the service. For guidance on this aspect of Office 365,
see Plan for Directory Synchronization at
http://www.microsoft.com/online/help/en-us/helphowto/14e35777-ebf6-
4cbc-a3ea-b5d600f78b4f.htm, and Active Directory Synchronization
Roadmap at http://onlinehelp.microsoft.com/en-us/office365-
enterprises/ff652543.aspx.
Complete the import of appropriate publicDelegate attribute information into
Office 365 using configuration files collected immediately after transition.
This import is conducted after the completion of the first full directory
Synchronization. For more information, see Preserving the Public Delegates in
Section 3.
Monitor your help desk tickets and escalation(s) for trending on issues and
coordinate their collection and reporting through your support infrastructure.
Convert BPOSS shared mailboxes (that require a paid license) to Office 365
shared mailboxes (that do not). For more information, see Converting Shared
Mailboxes in Section 3. Shared mailboxes from BPOSS will continue to
function without this conversion: they just consume a license. This means
that business process or applications depending on these shared mailboxes
are not impacted by the timing of this post-transition change and you can
make this change when you need to reclaim the licenses for other use.
(T+84:00 Hours) Post Transition

General Activities
Validation that all service items are complete, Microsoft support returns from
transition support to normal operations.
Customer transition help desk restored to normal operations (assuming you
judge this prudent based on call volumes into the help desk).
(T+2 Weeks) Post Transition

General Activities
Schedule implementation dates for removal of the BPOSS firewall and port
assignments for services which are now unnecessary after transitioning from
BPOS to Office 365. Be careful not to make changes which disrupt the running
Office 365 services.
Office 365 is changing how email is routed to your organization in order to
provide continuing improvements in performance and stability. To make email
routing more efficient, this change requires each custom domain to have a
unique Mail Exchange (MX) record value. Post-transition, please update the
MX record for any of your custom domains that points to
mail.global.frontbridge.com. This change should be done after other
transition related activities are completed. It will not affect mail flow to your
organization.
To find the new unique value for the MX record:

In the Admin page of Office 365, under Domains, click
Management.
Select a domain, and then click DNS settings. Keep this page open or
print it.
At your domain hosting service, go to the page to change DNS settings
and open the MX record that points to mail.global.frontbridge.com.
Replace mail.global.frontbridge.com with the value in the Points to
address column in the MX record line of the Exchange Online
section of the Office 365 DNS settings page. This value will be in the
format <DomainSpecificValue>.mail.eo.outlook.com.
Start planning work for the adoption of new features of Office 365. If you
started planning work for new features in advance of transition, this may be
the timeframe for you to commence execution of those plans. Depending on
your urgency and the state of your planning, certain new features can be
executed sooner than this timeframe, such as commencing Lync Federation
to business partners, or implementing single sign-on with ADFS).
Schedule a visual upgrade for Sharepoint 2010. SharePoint Server 2010
includes a new appearance and a new master page layout. After the
transition, the Site Collection Administrator has the option to upgrade the
visual aspects of each individual SharePoint site or sites. After you run Visual
Upgrade on a site, new features such as the ribbon and new master page
layout are available for that site. For directions, see How to run Visual
Upgrade on a SharePoint site that was transitioned from Business Productivity
Online Suite to Office 365, at http://support.microsoft.com/kb/2630870.

Section 3: Technical
Considerations

Overview
The changes between BPOSS and Office 365 fall into two broad categories as
described in the following table:
Improvements and changes to features used by end-users, email
administrators and SharePoint content administrators.
Differences in infrastructure and technical requirements. The rest of Section 3
provides details for these infrastructure and technical requirement issues.
Category
Description
Improvements and changes to A full review of the many improvements and changes in this
features used by end-users, email category is beyond the scope of this document. It is critical to
administrators and SharePoint fully study the Office 365 Service Descriptions and to
content administrators. comprehensively evaluate a trial tenant in order to understand
the changes between BPOSS and Office 365. There are changes
This category also includes
that impact the users and administrators in the functions they
business and application
perform already on BPOSS, and there are changes that are new
functionality that works differently
features that users and administrators can take advantage of.
in Office 365 compared to BPOSS.
Some of the key user or administrator impacting changes are:
For example:
SharePoint is upgraded to SharePoint version 2010. Certain
Web Parts and controls are no longer available, and there are
Administrators will use the
UI changes. Pages should be tested to ensure they work and
consolidated Office 365 portal,
render successfully. Any workflows that were in place in
rather than the separate
SharePoint 2007 need to be verified as working in SharePoint
administrative portals in
2010.
BPOSS.
LiveMeeting functionality is not offered in Office 365, and

End users will see new web
sunset of this offering has been announced. With the right
conferencing UI and features
technical planning, you will still be able to use LiveMeeting
since they will now be using
for a period of time after transition, as it will not sunset
Lync Online rather than
immediately. However, you need to start the adoption of
LiveMeeting.
Lync online as your web conferencing service. There are
many benefits of adopting Lync Online, but there are also
The parameters which control
impacts to end users and conference organizers that need to
the maximum number of email
be planned for.
message recipients, maximum
size of an email message and
Tenant portals are consolidated. Your tenant administrator
the maximum number of email
will not have to use different online portals for different
messages that can be sent in a
tasks, but can access all aspects of the service from the one
given timeframe are different
online portal. The role of Windows Live credentials has been
between BPOS S and Office
deprecated from the solution for administrators. Every
365.
administrator of the Office 365 service for your organization

will be required to have a valid license and password to
administer the service.
User sign on experience has significantly changed, and is

seamlessly integrated into the function of the Microsoft
client software. Client software and SharePoint sites will
prompt for passwords where they did not before. To avoid
help desk calls, the users will need to fully understand this in
advance and this should be a key component of your
communications and training plan.
The impact of client software changes on end users should not

be trivialized. Particularly if the users are coming from Office
2003, users will notice many changes including UI changes, a file
format change, and subtle functionality changes, as well as new
functionality available in all applications. Keep in mind, for many
companies, the adoption of a new version of the Microsoft Office
software suite is a non-trivial IT project in its own right.
Differences in infrastructure and The key changes in infrastructure and technical requirements,
technical requirements between between BPOSS and Office 365 are:
BPOSS and Office 365 versions.
These items typically concern the Office 2003 is not supported. Outlook 2003 will not work with
IT department and not users Office 365 at all.
directly.
Office Communicator 2007 used with Office Communications
For example:
Online will not work with Lync Online in Office 365.
Outlook 2003 is not supported Internet Explorer 6 with the Microsoft Online Administration
in the Office 365 service. Center, My Company Portal or Outlook Web App is not
supported, and Office 365 will behave erratically if Internet
BPOS S permitted the Explorer 6 is used to access the service.
Active Directory User
Object to have a UPN The remainder of Section 3 in this document is focused on
attribute without a planning areas associated with technical details, requirements or
matching SMTP address. consequences in this category. You should also study the Service
Descriptions closely to find the particular items that might apply
Office 365 does not.
in your environment.

Software Requirements
To be compliant with the minimum requirements for Office 365, Microsoft requires
that customers meet the following standards and versions: Office 2007 SP2, Internet
Explorer 7, and Windows XP SP3. The full list of software requirements is included in
the section below. The best experience in Office 365 is achieved by being on the
latest versions of all user client software.
Operating system requirements

Windows XP SP3
Windows Vista SP2
Windows 7
Mac OS X 10.5 (Leopard), 10.6 (Snow Leopard)
Office client requirements

Office 2007 SP2 or Office 2010
Office 2008 for Mac & Entourage 2008 Web Services Edition
Office 2011 for Mac and Outlook 2011 for Mac
.NET 2.0 or later
Lync 2010
Browser requirementsAdministration Center and

My Company Portal
Internet Explorer 7 or above
Firefox 3 or above
Safari 4 or above
Chrome 3 or above
Browser requirementsOutlook Web App

Internet Explorer 7 or above
Firefox 3 or above
Safari 3 or above on Macintosh OS X 10.5
Chrome 3 or above
Outlook Web App also has a light version that supports a reduced set of
features across almost any browser
The above requirements are subject to recurring change without notice. For the
most current information, see System Requirements at
http://www.microsoft.com/en-us/office365/system-requirements.aspx.

Sign In Credentials
After transition to Office 365, your users will sign in with exactly the same
credentials as they did in BPOSS before transition. For example:
Sign in before transition Sign in after transition
[email protected] [email protected]
online.com
.com
Note: If you have been working with an Office 365 trial tenant, you will have seen
that login credentials for users that were first created in Office 365 use a different
format (e.g. [email protected]). You do not use this format with your
users coming from BPOSS because their UPN has already been set by BPOSS and
does not change in the transition to Office 365. Note that users transitioning from
BPOSS will have an Office 365 style SMTP alias added to their user profile
([email protected]) as a convenience, but transition does not change
the UPN, logon credentials, or the default SMTP address for the user.
Required Password Changes

In order for a user to use their BPOSS password in Office 365 after the transition
from BPOSS to Office 365, it is required for every user to change their password in
BPOSS before the transition weekend. This is needed so the password can be
synchronized to Office 365 Microsoft cannot copy it to Office 365 due to the
encryption in use.
Any users who have not changed their password between T-60 and the transition
weekend will not be able to sign in to the Office 365 service after the transition
weekend without requesting password reset by one of your administrators.
At a minimum, it is critical that all your tenant administrators change their
passwords before the transition date, even if your end users are not required to do
so. Note that if you follow this Admin only approach, a password change request
will be generated for every user consuming the service immediately after transition,
which will create additional burden on your help desk and service administrators.
This is usually not acceptable or practical. If you have not changed the password for
substantially all of your users in the 60 days prior to transition, Microsoft may
contact you to suggest postponement of the transition. You should ensure your TAM
or STM is fully aware of the approach you have chosen.
Microsoft is closely monitoring the status of password changes by users in BPOSS
as transition approaches and your TAM or STM will be able to provide you an update
on password change status across your population of users and identify those users
who have yet to make a change.

Office 365 (and, since the third quarter of 2011, BPOSS) requires strong passwords
in order to protect users and their information. The password complexity
requirements for Office 365 are:
It is 8 to 16 characters long.
It cannot contain Unicode characters.
It must contain characters from at least three of these four categories:
o Uppercase letters: A-Z
o Lowercase letters: a-z
o Numerals: 0,1,2,3,4,5,6,7,8,9
o Non-alphanumeric characters: ` ~ ! @ # $ % ^ & * ( ) _ + - = { } |
[]\:";'<>?,./
Software Deployment and Packaging

As discussed in previous sections in this document, the software requirements for
Office 365 have changed from BPOSS, and additional planning has to be taken into
account in order to provide sufficient time to update software packages, regression
test applications in your environment, and ensure the functionality of the enterprise
well in advance of your planned transition date.
Microsoft provides the Office 365 desktop setup application which installs a set of
required updates to each PC that uses Microsoft client software (such as Microsoft
Office 2010) and connects to the Office 365 service.
Large enterprises typically use an enterprise deployment suite of tools to manage
and deploy software packages to the desktop. The settings for the installation of the
client components should be incorporated as part of the automated deployment
package. Most large enterprises will want to test the installation of the various
components as a precursor to transition in order to ensure applications function as
expected.
As discussed in Section 2, when working through the timeline for transition, the
following items should be reviewed as part of the planned deployment of the Office
365 service.
Adjustment of your desktop build images to ensure that the Office 365
Desktop Update application is part of your organizations build process and
desktop methodology (T-90 timeframe or earlier, but highly dependent on the
customers time needed to package and deploy).
Pre-transition installation of the Office 365 Desktop Update as part of the
software deployment strategy for usage of the Office 365 service (T-60
timeframe).
Manual Distribution of Client Updates

As you work to package your client software for automated roll out in your
organization, you also need to take into account specific updates and patches
needed to work successfully on Office 365.
Depending on your organizations infrastructure and lock-down policies, you may
need to push these patches to users computers through Microsoft Systems
Management Server (SMS) or Microsoft System Center Configuration Manager
(SCCM), group policy, or whatever other software distribution tool is part of your

official build process. It may not be practical for you to ask users to run the desktop
set up tool, and in many enterprises, the users do not have the rights on the
desktop to make the changes the Office 365 desktop setup tool makes.
For the most current, and up to date requirements, see Manually install Office 365
desktop updates at http://community.office365.com/en-
us/w/administration/manually-install-office-365-desktop-updates.aspx.

SharePoint Version Differences
The following Web Controls and Web Parts that were available in the BPOS version
of SharePoint Online are not available in Office 365 SharePoint Online:
Asp:xml
XmlWebPart
RSSAggregatorWebPart
RegularExpressionValidator
DataViewWebPart
CreateUserWizard
ChangePassword
The BPOS -S server control RequiredContentPlaceholder is deprecated in Office 365
and will redirect to a blank page.
Office 365 SharePoint Online blocks/permits the upload of various file types as per
the specification of SharePoint 2010, but with the following changes:
.htc files are permitted
.json files are blocked
Lync Deployment
In addition to updating the Office and Internet Explorer software, the Office 365
transition will upgrade the instant messaging and Web-conferencing functionality
from Office Communicator Online to Microsoft Lync Online, requiring the use of the
new Microsoft Lync 2010 software client.
Microsoft offers a staged approach to the deployment and usage of Lync as part of
the adoption of Office 365, so that the degree of change is greatly reduced
immediately after transition.
You should plan for two deployment phases for the Microsoft Lync 2010 software,
covering the Microsoft Lync 2010 Client software upgrade and transition phases of
the project.
Lync Client Software Upgrade. Once you have been contacted by
Microsoft regarding your transition date, the new Microsoft Lync 2010 client
software will work with the BPOSS Communicator Online environment. You
must plan for the deployment of the Lync client in advance of the transition
date to avoid multiple changes during the transition weekend, or loss of
access to the IM and presence workload. If you have any third party local
customizations to your Lync client, they must be tested and integrated with
your Lync client before this deployment. (E.g. CUCiMOC).
This first stage is nonetheless a full production deployment of the Microsoft

Lync 2010 client, so you must ensure you have updated your support
guidance, help desk, and set your user expectations appropriately, according
to your normal change management approaches.
Typical timing for the deployment of Lync is from T-60 thru to T- 14

timeframe, however you must not attempt to install it before you are
confirmed to be in Microsofts pipeline for transition by receipt of a T-60 (or
nearer timeframe) notice.
Transition Finalization: During the transition weekend, the OCO service will
be transitioned from Office Communicator Online to Lync Online, and your
users experience will then transition to the full featured, rich functionality of
the Lync Online service described in the Service Description for Lync Online.
Additional communications in advance of this transition are recommended in
order to properly set user expectations. There is no customer IT activity or
special user steps required for Lync Online or Lync Client in this phase,
assuming it has been working in full production before transition.
Live Meeting
As referenced in other sections of this document, the Live Meeting client and service
will continue to work for some time after the transition to Office 365. Microsoft has
indicated that the service will be sunset, so you should still be planning to move
users off the service in an organized approach, so that you do not have to do this
suddenly in the future. The minimum client version supported for Live Meeting after
transition is 8.0.6362.202, and you should ensure your organization meets these
minimum requirements in advance to reduce the impact of inconsistencies with
earlier versions against the service.
There is no specific timeframe for migrating to the latest version of Live Meeting
Client, and user disruption for this update should be minimal. Most IT organizations
probably already have a program in place for keeping the Live Meeting client
software up to date.
Once transition is complete, in order to schedule new meetings within Office Live
Meeting 2007 from within Outlook, you will have to re-install/deploy the Outlook
Plug-In for Live Meeting, as the desktop setup for Office 365 will deactivate this
plug-in, and it will no longer function. All previously scheduled meetings will remain
in effect in the service, and will be available after transition to Office 365.
Your adoption plan for Lync Online should include re-establishing those meetings
into Lync Online Meetings, which is a task that must be conducted by the end-user
meeting organizer for each meeting.
Transitioning to Lync Online includes two related efforts: (1) ramping down your
Office Live Meeting 2007 usage and (2) rolling out the use of Lync Online for Web
Conferencing to your organization.
Key actions that may require the involvement of your project team may include
some or all of the following. The items in italics must be performed by the end-user
conference organizer or conference content owner. Your help desk should plan
accordingly. The other items can be performed centrally by IT assuming the
appropriate remote workstation management software is in place.
Deployment of Office Live Meeting Client 8.0.3.6362.202 or later, ideally
before transition.
Deployment of the Outlook Plug-In for Office Live Meeting 2007 after
transition T-00.

Validate all existing, recurring, and future Office Live Meeting 2007 meetings
post-transition (T+8 and onwards) and convert to Lync Online meetings
where appropriate, based on your Lync Online adoption plan.
Download and save any important recordings, content or reports from the
LiveMeeting Service.
Delete LMS conference center URL and/or LMS Portal from your favorites.
Uninstall the LMS client and add-in (when you no longer offer the Live
Meeting service in your environment).
Decommission any Live Meeting Service Portal that is operated on-premises
(when no longer needed in your environment).
Additional information on the Live Meeting 2007 client and where to download the
appropriate updates can be found at Download the Microsoft Office Live Meeting
client at http://office.microsoft.com/en-us/help/download-the-microsoft-office-live-
meeting-2007-client-HA010173383.aspx
Microsoft has published various articles about Live Meeting-to-Lync transition-
related resources, and the references below should be considered the up-to-date
source of information. However, LiveMeeting can be subscribed to in many different
ways, including directly without a BPOSS subscription. Much of the content below is
written to be generally applicable in various different provisioning scenarios for
LiveMeeting and you should review and consider the content selectively for
applicability in your BPOSS to Office 365 scenario.
Live Meeting-to-Lync Transition Guide
http://technet.microsoft.com/en-us/lync/hh182968
Transition Planning Resources
Transition Support
http://www.livemeeting.com/ask
Update DNS Settings for Outlook

You will need to create or update the following CNAME record. If you have more than
one domain that you currently use with BPOSS, you will need to create an
Autodiscover CNAME record for domain. The autodiscover records are created in
addition to existing records supporting the service, so there should be no impact to
the BPOSS production environment. There is no need to change your MX records as
a prerequisite for transition, as FOPE will route mail appropriately as part of the
transition process.
Type Name Target

CNA Autodiscover.your domain Autodiscover.outlook.com
ME
For more information, see Use a CNAME record to Enable Outlook to Connect, see
http://help.outlook.com/en-us/140/cc950655.aspx.

Authentication
Before transition, users use the Microsoft Online Services Sign In client to
authenticate to all BPOS services. After transition, you have the option to implement
single sign-on (SSO) via identity federation.
Microsoft Online Services Sign In Client

Caution: Though the Microsoft Online Services Sign In client application has
been deprecated for Office 365, it is required during and immediately after
transition. It should not be removed from end-user computing platforms until all
users have signed in to Office 365 for the first time.
Every user must have the Microsoft Online Sign In client application
running at the time of their first attempt to use Office 365 post-transition
and they must sign in using this client post-transition.
Removing it early will impact users transition to Office 365, and require
manual remediation of Outlook connectivity issues, including but not
limited to re-downloading all mail content from Office 365. If you have any
users who do not sign in one time with the sign in client by the time you
remove it from your environment (e.g. users on vacation), these users will
be unable to access Office 365 and your administrator will need to call
Microsoft support for remediation steps.
There is no downside to leaving the Sign-In client on a workstation, as it
will deactivate (but not uninstall) itself post transition when it has no more
tasks to perform.
Once transitioned and successfully authenticated for the first time, Office 365 users
will subsequently authenticate directly against applications within Office 365, with
the same credentials they had prior to the transition of the service (assuming the
guidance on password updates in this document has been followed), and post-
transition the Sign In client will perform no visible function for users and can be
ignored or uninstalled.
Single Sign-On
As part of the functionality improvements in the Office 365 platform, your
organization has the option to implement sign on to the service leveraging
enterprise credentials, also known as Single Sign On (SSO), via the use of Active
Directory Federation Services (AD FS).
Because the implementation of AD FS on your premises is an identity
management project in its own right, detailed guidance for its
implementation is outside the scope of this document. For more information
about post-transition implementation, see the Single Sign On Roadmap at
http://onlinehelp.microsoft.com/en-us/office365-enterprises/hh125004.aspx.
AD FS is typically set up after an organization transitions to Office 365. For
large organizations transitioning from BPOS, this can be confusing for users,
as they will have three different sign-on experiences - one for BPOS, one after
transition to Office 365 while AD FS is being implemented, and one after full
ADFS implementation. As an alternative, there is a process by which
organizations can enable ADFS prior to the transition to Office 365, referred

to as early ADFS. This process is not supported for all organizations, and
requires assistance from Microsoft.
To request access to the early AD FS process, please contact your Technical
Account Manager (TAM), Service Transition Manager (STM), or BPOS Support.
Service Connectivity
Many Office 365 Internet IP addresses, URLs and fully qualified domain names, in
addition to network ports, are different in Office 365 than in BPOSS. Once you are
running Office 365, these items are also subject to occasional changes as part of
the ongoing enhancements to the Office 365 service. As part of the discovery
process, and leading to the scheduled transition date, all network traffic load-
balancing, firewall configurations, reverse proxies and NAT configurations must be
investigated and tested with Office 365 to ensure expected functionality and
availability of the service both during and after the transition. This testing should be
conducted with your trial Office 365 tenant as described in Office 365 Trial in
Section 1. Any changes you need to implement should be carefully planned to
ensure you do not impact the accessibility of the production BPOSS service during
the pre-transition phase.
You should investigate if your networking services team uses IP addresses in firewall
and proxy configurations. Microsofts recommendation is to use wildcard domain
names in any network access control solution because Microsoft IP addresses are
subject to change without notice both as part of this transition and ongoing in the
production services.
Mobile Devices
Just like BPOSS, Microsoft Office 365 for enterprises provides mobile device-based
access to the service, including email, calendaring, and contact information. As part
of the transition process, at the time the mailbox is moved to Office 365,
ActiveSync, POP3 and IMAP4 mobile devices will lose access to the service as the
server details will change. The timing of when you prefer your users to reconnect
mobile devices is at your discretion, as you may want to wait until IT can apply
policy, which you can only do after transition is complete. Before transition, you will
need to provide communication to your users with information about how they can
reconfigure the devices. The soonest they can do so is after their mailbox transition
has completed, which happens at some point during the transition weekend
between T-0 and T-00. The timing of when a users mailbox is transitioned and the
actions they take to reconnect is discussed in User and Administrator Impact During
the Transition Weekend in Section 2.
If you have a sophisticated mobile device management (MDM) solution in place,
adjustments for mobile devices may be possible centrally, but if not, you should
prepare your users to make these changes.
To avoid mobile devices, and POP or IMAP clients, pulling down all pre-existing mail
to the client/device again, it is recommended to make IP/URL changes to existing
client profiles, rather than recreate new profiles.
You should also prepare the help desk for calls on this topic because the best
communications plan will miss some users, and the most likely people to be missed

are the highly mobile users who rely on their mobile devices. Additionally this may
be more technical task than many users are comfortable with.
If you have or intend an MDM solution to be used with Office 365, this should be
very thoroughly tested in advance in a lab environment with a trial tenant, trial
devices and test accounts. The technical requirements for interfacing with Office
365 are described in the Service Descriptions and software that doesnt meet these
requirements is unlikely to work acceptably.
Guidance on mobile devices and configurations for Exchange ActiveSync can be
found in Use email on your mobile phone at http://onlinehelp.microsoft.com/en-
us/office365-enterprises/ff637599.aspx . For specific and current guidance for your
specific mobile devices, see the Mobile device setup wizard at
http://help.outlook.com/en-us/140/dd936215.aspx.
Mail-Enabled Applications
If your organization has any line of business applications that require messaging
capabilities, you should spend time during the pre-transition phase, typically before
T-60, given the scale of possible remediation work to your applications, to determine
whether they need to be modified to work with Office 365. In most cases,
applications that are currently consuming the BPOS service will require at most
minor modifications to the mail configuration in order to properly point to the
appropriate SMTP gateway to route mail through the service.
Note that any applications directly accessing Microsoft Exchange Online in Office
365 need to be based on Exchange Web Services (EWS). Applications based on
legacy interfaces or APIs for Exchange Online will not work.
Examples of applications that should have their mail-enabled functionality checked
and confirmed are:
Reports that are automatically generated by a line of business application
and sent via email to an email address or a distribution group.
Applications that use telephony systems including fax solutions.
Applications that interface with MS Exchange and monitor or interfere with
mail flow (e.g. MDM applications or DLP applications)
Message Routing and FOPE

Most IT organizations which consume the BPOSS service today have configured
their inbound MX record to point directly to the BPOSS services. In this
configuration, no changes will be needed to this mail routing in preparation for
transition to Office 365. New inbound mail will be preserved during transition. If you
have your own solution for inspecting inbound messaging before routing to the
BPOSS Service, you will need additional configuration work in order to ensure that
the mail forwarding rules are configured properly, and that the Office 365 service
recognizes and accepts mail from these senders.
If you have not implemented a Sending Policy Framework (SPF) record for your
SMTP domain, it is recommended that you do so as part of your pre-transition
strategy to avoid future disruption if your ISP should make a change to SPF
enforcement. SPF records in DNS are inconsistently implemented by ISPs at this

point in time. There is no particular point in the transition timeline where this must
be conducted, and it is not a requirement for transition to succeed.
FOPE settings are not changed during transition process. However it is strongly
recommended that if your organization operates any custom DLP type solutions for
outbound mail processes, then these are tested in advance of transition with a test
tenant to ensure there are no issues that would prevent the flow of messages
between the organizations. While the transition design-point is that all FOPE settings
will transition over to the Office 365 service, Microsoft recommends that you
document all FOPE settings before transition so that should there be any need to
manually update settings due to unforeseen transition issues, you will have the
appropriate configuration documentation ready, reducing the time it takes to re-
apply these settings.
With BPOSS, your mail administrators had no admin access to the FOPE console.
Changes were applied via Microsoft Support. After transition to Office 365, your
administrators will have access to the FOPE console and will be able to make their
own adjustments. This removes the dependency on Microsoft Support for routine
mail configuration and puts more control of the end-to-end email flow solution in the
hands of your administrators. You should prepare for this by working with a
Microsoft Office 365 tenant trial subscription as part of your readiness work and mail
administrator training.
You may have to take custom manual steps with FOPE if you are using a separate
instance of FOPE to protect a mail solution other than the BPOSS solution. Please
contact your TAM for advice if you have a standalone FOPE subscription in addition
to the FOPE subscription that is provided for Microsoft Online Services.
Exchange Hosted Archive (EHA)

Starting in calendar year 2012, Exchange Hosted Archive (EHA) will enter a sunset
phase, and Microsoft will offer a new service based on Exchange Online Archive
(EOA). Existing EHA customers will be provided licenses to EOA as part of the
transition, and Microsoft will relocate their archive data from EHA to EOA at a future
point in time, with a transition plan that has not been announced at the time of this
writing.
This EHA transition to EOA will not occur at the same time as BPOSS transition to
Office 365. After the transition to Office 365, journaling to EHA will not be impacted.
EHA will still be consumed as it is currently within your organization. You will later
participate in an entirely distinct transition process from EHA to EOA.
Note that attempts to manually transition from EHA to EOA are not supported, and
run the risk of data loss, gaps within your archive, or in the worst case, the EHA
archive can be summarily deleted without possibility to recover. This is one of the
key reasons manual transition is not supported.
Blackberry (RIM) Devices

Customers who are currently using Blackberry/RIM in their BPOSS environment are
probably already aware that Microsoft will no longer offer a Microsoft hosted
Blackberry Enterprise Server (BES) service as part of Office 365. RIM Corporation
will be providing a cloud BES service that integrates directly with Office 365, using

our established guidance for third party service providers. RIM has named this
service Blackberry Business Cloud Services for Office 365.
As part of your planning for BES devices in your organization, you will need to
prepare to enter into a contract with RIM to consume their service after the
transition. During transition planning, you are encouraged to pre-screen this
contract with RIM to check the service features and contract attributes meet your
needs. The pricing and features of the service from RIM is determined by RIM and
not by Microsoft.
Until the timing of transition to the RIM BES service is confirmed by RIM and
Microsoft, customers will not be scheduled by Microsoft to transition due to their
dependency on Blackberry devices. However, even if you are delayed from
transition due to the timing of availability of the RIM BES service, you should not
delay your other readiness activities as described in this document.
The best way to make sure you can transition smoothly and quickly once the RIM
BES service is available is to conduct your readiness activities as if transition to
Office 365 is imminent. None of the work you do in advance to prepare for Office
365 will expire or lose its utility due to the wait for the availability of the BES RIM
transition.
The most current information for the status of the RIM service can be found at
Blackberry Business Cloud Services for Microsoft Office 365 at
http://us.blackberry.com/business/software/cloudservices.jsp .
SR Review
As stated earlier in this documentation, an IT department using BPOSS should
ensure they have documentation of their end-to-end service based on their BPOS-S
tenant, including, among other configuration items, the customizations that have
been implemented by Microsoft on their behalf via SR.
One of the potential areas you should plan for during the transition of service is any
unforeseen scenario where you need to re-apply any Service Requests (SRs) from
BPOSS to Office 365. Most items implemented through the SR mechanism
transition without customer action to Office 365. Those that dont transition have no
impact on service availability in Office 365, or are no longer supported in Office 365.
Time spent in the research and documentation of your customizations is a good
investment in order to smoothly transition to Office 365 with a minimal impact to
your customers if things do not go exactly to plan.
You will need to check which of your BPOSS customizations are meaningful in
Office 365 and confirm they are implemented again after transition, if they are
available and necessary in Office 365. Post transition validation in the T-00 to
T+8hours is a perfect time to do this, if you are prepared in advance.
After collecting the list of SRs, you need to validate them against the Office 365
Service Descriptions in order to ensure applicability with the new service, and to
determine how to configure your environment after the transition. The changes will
most likely fall into the following categories:
Feature decremented and unavailable in Office 365. If you have a
critical need for a feature in this category you will need to plan for a
remediation strategy to provide an equivalent capability in Office 365. Please

contact your TAM or Microsoft representative if you need help with
customizations falling into this category that might prevent your transition to
Office 365.
Capability available natively in Office 365. In most cases, service
functionality that was implemented with an SR will most likely be
implemented (or available) by default as part of the new service offering. You
will need to configure the settings for these features as appropriate, and
confirm/validate the operation of your services that depend on that
functionality. Key settings such as IMAP/POP availability and ActiveSync
availability are on and available by default in Office 365. Consequently, your
plan may need to be to implement the inverse of the original customization.
For example you may have to configure to turn off these features for users
who should not have them, rather than to turn them on for people who
should as you did in BPOS S.
Feature not standard in Office 365. This will be include items that while
available in the platform, are not supported without a SR being filed. Its
important to work closely with Microsoft to ensure the required functionality
can be implemented via the SR process. There are very few items in this
category. With Office 365, Microsoft has significantly increased the extent to
which the user can customize service features directly. At the same time
Microsoft has increased the degree to which standardization and automation
is used across the solution, making per-tenant customizations much more
challenging.
Office 365 makes it possible to achieve most points of configuration using the Office
365 UI, PowerShell or an on-premises Exchange Admin Console (in hybrid
configurations), so there is a significantly reduced need to make routine production
changes to the operation of your tenant by creating a Service Request to Microsoft
Support.
Migration of Settings and Configuration

As a part of the pre-transition documentation of the current BPOS environment, you
should be aware of what settings will and will not be transitioned into the Office 365
service. Any settings not transitioned as part of the Microsoft process will be the
customers responsibility to apply or configure in the Office 365 service during the
post-transition (T-00 to T+8) period to achieve equivalent service functionality.
Not
Transition
Configuration Item Transition
ed
ed
Administration
X
Service requests (Most are no longer relevant, or
available)
X
Verified domain

X
Unverified domains
X
Security groups
Licensing and Subscriptions

X
Licensing Information
X
Subscription Information
Users
X
Outlook client customizations (e.g. Views)
X
User mailboxes
X
Primary and alternate email addresses
X
Email (Inbox, Sent, Deleted, Draft, Conversational,
Junk, Retention)
X
Outlook Calendar/Meetings
X
Outlook Contacts
X
Outlook Notes
X
Delegate permissions
X
Forwarding
X
Mailbox permissions (Full Control, Send As, Receive
As)

Outlook server-side rules
If per user rule quota was increased above 64k, all
rules will be migrated; however, you will not be
able to manage or change the rules until you X
delete rules to fall below the Office 365 space
allowance. At the time this document was written,
per user rule quota increase is not included in
Office 365.
X
POP3 access settings (Enabled/Disabled) (On for
all by default)
X
IMAP access settings (Enabled/Disabled) (On for all
by default)
X
Outlook Web App access setting
(Enabled/Disabled) (On for all by default)
X
ActiveSync access setting (Enabled/Disabled)
Exchange Online
X
Safe senders
X
Blocked senders
X
Distribution groups
X
Organization contacts
X
Conference rooms
Office Communications Online (OCO)
X
OCO contacts
Live Meeting

X
Scheduled meetings*
Recordings and other content (not migrated to X

Lync remains in LiveMeeting)
Special requests
X
Security groups
X
Retention policies
X
Disclaimer transport rules
X
ActiveSync policies (on by default for all users)
X
Journaling rules
X
Password Never Expires setting
Forefront Online Protection for Exchange (FOPE)

settings
X
FOPE company settings
X
FOPE domain settings
X
FOPE policy rules
X
FOPE footer rules
X
FOPE users
* As noted within this document, Live Meeting will continue to work after transition, but will only be
available for a limited time. Customers should plan to switch to Lync Online for web conferencing.

As can be seen from the table, most customizations that have an impact on the user
experience or tenant functionality are transitioned automatically. Regardless, it is
still good IT practice to have your custom configuration fully documented.
Network Bandwidth Reassessment

The Office 365 service offerings may increase your organizations Internet traffic,
potentially increasing bandwidth needs if you introduce new features such as peer-
to-peer voice and video via Lync Online. It is helpful to evaluate and assess the
network impact of the services as part of an ongoing process to ensure your
organization is optimally configured for the usage of the service.
There are many variables to consider when estimating network traffic. Some of
these variables are:
The Office 365 service offerings that your company has subscribed to.
The number of client computers in use at one time.
The type of task each client computer is performing.
The capacity of the network connections and network segments associated
with each client computer.
Your companys network topology and the capacity of the various pieces of
network hardware.
For helpful information to estimate the network bandwidth your organization will
require when using Exchange Online and SharePoint Online, see the TechNet article
Company Network Requirements at
http://technet.microsoft.com/library/cc745931.aspx. For information about
bandwidth requirements for Lync Server 2010 conferencing, review the TechNet
article Defining Your Requirements for Conferencing at
http://technet.microsoft.com/library/gg398341.aspx.
The pre-transition phase provides your organization with an opportunity to analyze
network port utilization and network bandwidth at peak usage. If you determine you
are at risk of port exhaustion or bandwidth saturation you should acquire additional
IPs for your internet access solution or acquire additional bandwidth. Additionally
the adjustments to Outlook applied by and described in KB2544404 (Outlook 2007)
and KB2544027 (Outlook 2010) can improve the efficiency of the way Outlook uses
connection ports. If you have kept Microsoft Outlook fully up to date in your
environment, you will already have these updates in place.
Determination of Administrator Roles

In BPOS S, administrative user accounts were broadly empowered in the service. In
Office 365 the following administrator roles are available to provide granular control
over which administrative responsibilities can be performed by which user account:
Billing administrator: Makes purchases, manages subscriptions, manages
support tickets, and monitors service health.
Global administrator: The top-level administrator in your company. When
you sign up to purchase Office 365, you become a global administrator.
Global administrators have access to all features in the administration center
and only global administrators can assign other administrator roles. There
can be more than one global administrator at your company.

Password administrator: Resets passwords, manages service requests,
and monitors service health. Password administrators can reset passwords
only for users and other password administrators.
Service administrator: Manages service requests and monitors service
health.
User management administrator: Resets passwords, monitors service
health, and manages user accounts, user groups, and service requests. Some
limitations apply to the permissions of a user management administrator. For
example, the user management administrator cant delete a global
administrator, create other administrators, or reset passwords for billing,
global, and service administrators.
During the pre-transition phase you should consider which administrative roles
should be held by which user accounts. You cannot apply the settings prior to
transition completion, but by designing the paradigm in advance, you will be able to
apply it quickly post transition, and can train the administrators on their new and
changed responsibilities in advance. This is not required for transition, but because
it is a new feature that many enterprise Office 365 customers will want to
implement if using Office 365 in full production, the requirements need to be
thought through so you can configure Office 365 immediately after transition.
For general information about administering your account, see the help topic About
administering your account at http://onlinehelp.microsoft.com/en-us/office365-
enterprises/ff637579.aspx. For information about Exchange administrator roles, see
Understanding Role Based Access Controls at
http://g.microsoftonline.com/0BD00en-US/250.
Deploy Directory Synchronization for

Office 365 Post Transition
Once the transition process has been completed, and all services have been
validated as part of the solution, one of the final remaining tasks is to complete the
upgrade to the Directory Synchronization Tool for Office 365. The BPOSS version of
the Directory Synchronization Tool (DirSync) will become non-functional during the
transition weekend, and will need to be re-established once the post-transition
validations have been completed and after you have captured the public delegates
configuration described below.
The new version of the Directory Synchronization Tool now supports the x86 and
x64 platforms, which gives customers additional flexibility in regards to their
deployment. The configuration of the Office 365 directory synchronization service is
broken down into the following tasks:
Removal/uninstallation of the existing BPOS Directory Synchronization tool.
Download of the updated Office 365 Directory Synchronization tool (32-bit or
64-bit).
Installation of any new hardware that may be intended for directory
synchronization.
Installation and upgrade of Office 365 Directory Synchronization tool.
Validation that the Directory Synchronization service is working and
synchronizing correctly.

The installation of the Directory Synchronization tool post-transition will require a
full synchronization of the directory and this cannot be performed until between 24
and 72 hours after transition is complete, as described earlier in Post Transition in
Section 2.
A full list of upgraded features of the Office 365 Directory Synchronization tool can
be found in the documentation that is downloaded with the tool. The most up-to-
date version of this guidance can be found in the help topic Install and Upgrade the
Microsoft Online Services Directory Synchronization Tool at
http://onlinehelp.microsoft.com/en-us/office365-enterprises/ff652545.aspx.
If you are going to be using directory synchronization between your on-premises
Active Directory and Office 365, it is crucial your directory meets the directory
requirements for Office 365. These requirements are documented in the Office 365
Identity Service Description, which can be downloaded from
http://www.microsoft.com/download/en/details.aspx?id=13602. Review the Active
Directory Considerations section in this Service Description, and include project
activity during your pre-transition phase to confirm your Active Directory content is
compliant with Office 365.
Note that unlike BPOSS, Office 365 requires the User Principal Name (UPN)
configured in your directory to precisely match at least one SMTP address
configured for that user. If this is not the case, your transition may be delayed until
your directory meets this and the other above requirements. The SMTP address
selected to match the UPN does not need to be the primary SMTP address for that
user. However it is critically important that a users UPN is not the SMTP address of
a different user in BPOS S. This could delay your transition or result in the loss of
mail for one or the other user during transition unless corrected.
Preserving Public Delegates

Customers who have used Public Delegates settings in BPOS have additional
activities to perform once the transition to Office 365 has been completed and
before Directory Synchronization can be established. This is specifically targeted at
those transitioning users who are migrating from BPOSS to Office 365 and have
both of the following scenarios in your environment:
You have users who have been setting the SendOnBehalfof property on their
BPOSS Mailboxes. (This can be set within Outlook when a user grants
permission to someone else.)
You plan to use the Directory Synchronization Tool for Office 365 in order to
sync from an on-premises Active Directory environment to the Office 365
tenant. This may be required because you were using DirSync in BPOSS or
because you want to start using Directory Synchronization for the first time
once you are native in Office 365.
If you meet the above criteria, then the following steps in this section must be
completed before starting the initial on-premises Active Directory to Office 365
directory synchronization (which is possible between 24 hours and 72 hours after T-
00). A failure to complete these steps in advance will result in the loss of these
current configuration settings that will have transitioned successfully from BPOS -S

but will be overwritten by Office 365 directory synchronization with null values from
the on-premises Active Directory.
In Office 365 and the associated Exchange Online Service, the mailbox users
SendOnBehalfof attribute configuration is an attribute copied by the DirSync
process from the on-premises Active Directory to Office 365. In the BPOSS version
of DirSync this was not the case. When the on-premises to Office 365 directory
synchronization process is first initiated, the on-premises user objects value for
publicDelegate will be null and will overwrite the values that have been populated
in Office 365 by the Microsoft BPOSS to Office 365 transition. Therefore, it is
necessary to capture and save this configuration information before the initial
directory synchronization.
This task should be done after the tenant has completed their migration from BPOS
to Office 365 and before executing the initial run of Office 365 Directory
Synchronization Tool.
If you need to perform this task, the required Exchange PowerShell scripts can be
requested from Microsoft Online support, and they will also guide you through the
process. Support can also describe other less common attributes that require the
same procedure.
Converting Shared Mailboxes

Office 365 offers an additional benefit in the ability to configure shared mailboxes
that are not user specific and do not consume a license. The only requirement is
that any user who accesses these mailboxes has a license. BPOSS did not have this
class of mailbox and Shared Mailboxes did consume what was effectively a user
license. After transition to Office 365, your shared mailboxes will be configured as
user mailboxes in Office 365.
The only way to create an Office 365 shared mailbox that does not need a license is
via remote PowerShell. For information about how to create a new shared mailbox in
Office 365, see Set Up a Shared Mailbox at http://help.outlook.com/en-
us/140/ee441202.aspx.
You will also use the same Set-Mailbox cmdlet scripting to reset the type of a user
mailbox to a shared type, after which you will be able to reclaim the user license for
a real user.
You can perform this conversion as soon as you are able to run PowerShell on the
new Office 365 tenants. This is only urgent if you need to reclaim the licenses for
other use.

Section 4: Client Experiences

Portals
The below authentication tasks assume an online identity, meaning your user
account and password are stored in the Office 365 online services environment. If
you are or will be using Active Directory Federation Services (ADFS) for online
services access, the below authentication steps will be very similar however with
proper ADFS and client/PC configuration, you as an end-user may never see
authentication prompts when access these services. If your Office 365 company is
using Active Directory Federation Services (ADFS) for authentication and you are
having authentication and/or access issues, you may want to check your local PCs
Internet Explorer configuration settings to make sure your ADFS URL, such as
sts.contoso.com, is listed as a Local IntranetSecurity Zone Site, listed within
the Security Zone section of the Internet Explorer web browser, as described below:
End-User My Company Portal

The Business Productivity Online Services (BPOS)My Company Portal is provided to
end-users in the form of the Company or Home Portal
(https://home.microsoftonline.com), which display links to Live Meeting, Outlook
Web Access, application downloads, help and how-tos and more. Once a BPOS
tenant has been transitioned into Office 365, users who login to the Home or
Company Portal will be provided a new Office 365 link, which will take them to their
new Office 365 environment. Since your BPOS account credentials have been
synchronized into Office 365 and therefore are the same, once logged into the BPOS
Portal and use the Office 365 link, you will be taken to the Office 365 login page and
granted access into the Office 365 Portal:
After Transition

Click Office 365 Portal Redirect into Office 365
Note Electing to check the Keep me signed in option will save the credentials
onto the local machine in Credential Manager (CredMan) and if users login to the
BPOS Home Portal and click the Office 365 link, they will be automatically
authenticated in Office 365 and not be prompted for username and password. This
BPOS redirect and login will be available for as long as the BPOS users credentials
are viable. Once the BPOS users password expires, the user will not be able to
login, they will receive a password change dialog box, which will allow the user to
change their password, but not be able to sign into the BPOS Home Portal. At this
point, the user MUST start using the Office 365 links.
Post-Transition with Password Expired
Successful Password Change Redirect No Longer Available

Administrator Microsoft Online Admin Center
(MOAC)
The Business Productivity Online Services (BPOS) Admin Portal, called MOAC, is
provided to Administrators, which display links to Service settings, user, contact and
group management and more. Once a BPOS tenant has been transitioned into
Office 365, Administrators who login to MOAC will be provided a new Office 365 link,
which will take them to their new Office 365 environment Portal. Since your BPOS
account credentials have been synchronized into Office 365 and therefore are the
same, once logged into the BPOS Portal and use the Office 365 link, you will be
taken to the Office 365 login page and granted access into the Office 365 Portal.
After Transition
Note By clicking the Office 365 Portal link, the online administrator will be taken
to the Office 365 Portal and on first login, the user will be taken to the Office 365
login page.
Click Office 365 Portal Redirect link

Note Electing to check the Keep me signed in option will save the credentials
onto the local machine in Credential Manager (CredMan) and if admins login to the
BPOS Home Portal and click the Office 365 link, they will be automatically
authenticated in Office 365 and not be prompted for username and password. This
redirect and login will be available for as long as the BPOS users credentials are
viable. Once the BPOS users password expires, the user will not be able to login,
they will receive a password change dialog box, which will allow the user to change
their password, but not be able to sign into the Microsoft Online Admin Center
(MOAC) Portal, as explained in the above end-user My Company Portal login section.
At this point, the Administrator must start using the Office 365 links.
Applications
Sign-in Client
1. Post transition, the end user will need to launch the Sign-in client and enter
the BPOS username/password. This is needed so that the users applications,
such as Outlook, can detect their BPOS mailbox has been moved into Office
365 and take the needed actions for tracking this moved mailbox down and
update the Outlook profiles connection settings.
a. Login will complete, but the Sign-in clients display will show no
services are available.

b. Notes:
i. The Sign-in client, upon login, will receive an indication to clear
the registry keys put in place to allow Outlook to connect to
BPOS. This will allow Outlook to automatically configure
successfully. This will also remove the default URL for Live
Meeting for BPOS to allow users to log into Live Meeting through
Office 365.
ii. The Sign-in client will continue to function, displaying only the
My Company Portal, for up to 7 days post-transition, at which
point the Sign-In Client will disable itself and no loger auto-sign
in. After this point, the Sign-in client can be safely uninstalled
through the Control Panel of the end user Operating System or
through an automated process controlled by the customer IT
staff.

Outlook
1. When user logs in to their computer after Transition, the Microsoft Online
Services Sign-In Client no longer displays the Outlook, Live Meeting, or Office
Communicator clients.
2. If Outlook is still running over the Transition Weekend, the Outlook client will
provide a prompt indicating that the administrator has made a change that
requires users to restart Outlook.
a. The end user will need to click OK and then restart Outlook.

3. You will need to open the Outlook client now from the program menu.
Internet Explorer
Internet Explorer should be configured to use with Office 365 even if it is not the
default browser. Configuring Internet Explorer allows your PC (not just the browser)
to determine when to release/send authentication credentials when requested from
either an online service, such as Exchange Online or if redirected to an internal
authentication endpoint, such as Active Directory Federation Services (AD FS). To
configure your Internet Explorer, please use the following settings:
Note: This setting should be used when using Active Directory Federation Services
(AD FS), as you will be redirected to your companys URL for authentication. The
below settings will remove the need for you to manually enter your domain
credentials and you will receive a pure Single Sign-On Experience (SSO).
Configure Internet Explorer
1. Launch Internet Explorer
a. Click the Tools Internet Options Security option
b. Click the Local Intranet option and then click Sites and then
Advanced

i. Enter the following into the Add this website to the zone:
dialog box
1. https://*.domain.com and click Add
a. Note Domain is the domain you use to login to
your PC with, such as contoso\alias or
[email protected]. In this scenario you would
enter: https://*.contoso.com, click Add and then
Ok out of all the dialog boxes.
Using this approach will allow your PC to automatically send your logged on domain
credentials to your ADFS server, so when you access Office 365 Online Services you
will not be prompted for authentication, but instead will be automatically logged
into the services and granted access.
Outlook Web Access (OWA)

1. If end users are logged into OWA when the mailbox is moved, end users will
be logged out. If the user attempts to login to BPOS OWA again, they will be
authenticated, determined to have been moved into Office 365 and
redirected to their newly moved mailbox:
BPOS OWA Login Screen
After successful authentication into BPOS OWA User is redirected to Exchange

Online 365 OWA Login page at http://mai.office365.com .
Office 365 OWA Login Page

The user can then login with the same credentials in order to access their Office
365 mailbox.
NOTE: If the users account information (i.e., password) has been changed after
the transition in Office 365, this redirection feature will cease to work and the
user should go directly to the new Office 365 OWA site at
http://mail.office365.com.
Redirect into Office 365 OWA Mailbox
a. Note The old BPOS OWA URL will be retired and should no longer be
used. This can be used for as long as the BPOS credentials are valid.
Once the BPOS users password has expired, redirect and the old BPOS
OWA link will no longer be usable.
2. End users will need to start logging into http://mail.office365.com and will be
redirected to a Windows Live ID credential page. This allows for users to start
using the new Office 365 OWA URL and no longer use the old BPOS OWA URL

and count on redirect capabilities. This redirect capability will only be
available for as long as the BPOS users password is valid. Once expired,
redirect capabilities are no longer possible.

Section 5: Appendices

Appendix A: Post-Transition Resources
This appendix contains details on post-migration testing and other post-transition
activities.
Post Migration Service Testing Activities

This section provides details for tests that must be done post-migration:
Validating the URLs for Office 365
Office 365 SMTP relay changes
Testing collaboration services
Validate URLs for Office 365

In the BPOS environment, there were multiple sites for both users and
administrators. In Office 365, there is only one portal, the Office 365 portal at
https://portal.microsoftonline.com. After you logon to the Office 365 portal, you can
navigate to the different services and administration pages by clicking the links that
are presented at the top of the web page.
Microsoft recommends that you bookmark the URLs, and publish them to the
appropriate communities for easy access using the table below. This table also
maps the old BPOS site names to the equivalent pages in Office 365.
BPOS Title Office 365 Title Direct URL

My Company Office 365 portal https://portal.microsoftonline.com
Portal
Outlook Web http://mail.office365.com

Office 365 portal
App
At the top of the page, click
Outlook.
SharePoint The URL for SharePoint Online is

Office 365 portal
Online unique for each organization e.g.
At the top of the page, click Team contoso.sharepoint.com
Site.
Microsoft Online https://portal.microsoftonline.com/ad

Office 365 portal
Services min
Administration At the top of the page, click Admin.
Center Admin features are only exposed to
users with admin permissions.
Microsoft Online Office 365 portal https://portal.microsoftonline.com/ad

Services min
At the top of the page, click Admin.
Customer Portal
In the left pane, click a link under
Subscriptions.
Microsoft Online N/A https://ps.outlok.com/powershell

Services
PowerShell URL

Office 365 SMTP Relay Changes
Changes to any SMTP enabled applications currently routing mail via BPOS are
required because the Office 365 environment requires authenticated access to the
SMTP relay and because the access URL will be different. Failure to properly identity
and modify those SMTP-enabled web applications may result in loss of functionality
as a result of the transition.
Identify SMTP-enabled web applications configured to use the BPOS. These servers
will need to be updated to use the Office 365.
Web applications or devices must be configured by using the following steps, as
settings previously configured for the BPOS Standard environment will no longer
work.
Once transitioned into the Office 365 service, these settings would need to be
applied in order to restore functionality. To restore the settings in Office 365,
perform the following actions:
Login to Office 365 Outlook Web App.
Click Options > See all options.
Click the Settings for POP, IMAP and SMTP access link on the main
page.
Use the information displayed for SMTP setting. This shows you the SMTP
settings for the mailbox associated with the credentials you logged in with.
Testing Collaboration Services Client Workstations

After you have completed the transition from BPOS to Office 365, its important to
have a valid testing plan to ensure all end-user accounts and their computers and
devices properly function within Office 365:
Workstation updates
o Desktop setup
o Manual patch/fix updates
Login and authentication
Accessibility and usability
o Rich applications (Outlook, Lync, SharePoint Workspaces (Groove)
o Outlook Web App
o Audio/Video
o Web conferencing
o Mobile devices
Windows phones
iDevices (iPhones/iPad)
Tablets (Windows, Android, etc.)
Testing Collaboration Services Exchange Online

have a valid testing plan to ensure all content has transitioned and functioning as
expected.

Mail routing
SMTP Relay (If used)
Messaging Routing and Hygiene Operations
Testing Collaboration Services SharePoint Online

have a valid testing plan to ensure all content has transitioned and is functioning as
expected. It may be necessary to test your SharePoint content to ensure that
SharePoint Online pages, web parts and components load, and behave as expected
after the transition. While the transition will not upgrade the visual style elements of
the existing BPOS environment for SharePoint in Office365, the underlying
components and infrastructure will be on the Office 365 architecture, which is
significantly enhanced from the previous version. Testing your uses of SharePoint
before the transition and associated remediation will help to ensure a smooth
transition to SharePoint 2010 in Office 365.
As part of the validation process, the following items should be reviewed in order to
ensure service functionality after the transition:
1. Name resolution and accessibility to the SharePoint Online Team Site.
2. URL Redirection and site links function as expected.
3. Pages render and display data as expected, with all controls and web parts
functional.
4. Permissions and site privileges remain intact post-transition.
5. My Company Portal functionality is validated.
For information about differences between the BPOS and Office 365 versions of
SharePoint online, see SharePoint Version Differences in Section 3.
Finalization of SharePoint Content Hierarchy
The structure of the team site in Office 365 SharePoint Online replaces the My
Company Portal structure in BPOSS SharePoint Online. As part of ongoing post-
transition actions, SharePoint content administrators should review and rationalize
their site hierarchies and access control lists. In the interim time until this can be
done, no content is lost and users will be presented with a page showing them all
the sites they have access to.
Testing Collaboration Services Lync Online

In order to test the functionality of Lync Online features and devices, you can
reference the following task checklist to ensure the Lync Online features are working
as expected. This should be done and validated before adding additional
functionality within Office 365 for your Lync users. Remember that Lync is deployed
in full production use between 60 and 14 days before transition, so this test plan (or
parts of it) may need to be conducted twice; once at Lync deployment and once
after transition.
Basic Lync Functionality
Sign in and sign out of Lync.
Sign in with a specified presence status

Contacts and Presence
Start an instant messaging (IM) session.
Send an instant message to multiple contacts in the Contacts list.
Invite someone to join an existing conversation.
Manually set presence status.
Validate the Do Not Disturb presence status.
Search for a contact using either first or last name.
Add a contact using the Search Results box.
View a persons contact card.
Person-to-Person calls
Call someone from your contacts list.
State an IM session and then add a Lync call.
Add desktop sharing to your IM and Lync conversations.
Lync Conferencing
Schedule an online meeting that uses dial-in audio conferencing.
Join an online meeting.
Mute and unmute meeting participants.
Share your desktop.
Share an application.
Share a PowerPoint presentation.
Upload an attachment to the meeting (if allowed).
Post-Transition Activities
The activities outlined in this section must be conducted after the automated
transition is declared to be complete and successful.
Activity/Task Objectives Required before
Users Access Tenant?
Confirm EHA journal Before production records are Yes, if you need to
is intact and created, you should send test document
journaling is running. emails and confirm they are confirmation that
archived according to journal mail is
compliance rules. This will help flowing and capture
you to demonstrate and evidence the journal
document the integrity of the is intact.
archive and well as conduct a
technical test.
Confirm mail routing FOPE is not changed during Yes, if you need
through DLP and transition. However it would be confirmation that
message hygiene prudent to test the DLP solution your DLP is working
solutions are not is still fully functional. and that mail is
impacted. flowing through it.
Configure Exchange Apply the pre-determined Yes, if you want to
Active Sync policy settings as defined. enforce a policy, e.g.

encryption or
selective availability.
Configure POP and Apply preconfigured user deny Yes, if access control
IMAP access decisions for POP and IMAP is required by your
access (these are on by default company policy.
for all users) and guide users
though getting access to
servers.
Configure Apply the pre-determined No. This is only
administration administration groups as required if you wish
groups determined in the pre- to limit the
transition work stream. capabilities of
administrators in
ways you could not in
BPOS.

Appendix B: Transition URLs, Ports and
IP Addresses for Office 365
Depending on your firewall approach and configuration you may need to open ports
in your on-premises firewall so network traffic originating from the Microsoft data
center IP addresses is allowed to enter your on-premises organization. Contact the
Microsoft Office 365 support team for IP address ranges requirements, or refer to
the help topic IP addresses and URLs used by Office 365, at
http://onlinehelp.microsoft.com/en-us/Office365-enterprises/hh373144.aspx.
Office 365 Portal

IP Addresses URLs/FQDN
111.221.111.196 portal.microsoftonline.com
65.52.196.64
94.245.108.85
65.52.208.73 passwordreset.microsoftonline.com
157.55.194.46
65.55.239.168 g.msn.com
207.46.216.54
207.46.73.250 g.msn.co.jp
94.245.117.53 g.msn.co.uk
Microsoft Online Services Sign In

IP Addresses URLs/FQDN
207.46.150.128/25 *.outlook.com
157.55.59.128/25 *.microsoftonline.com
207.46.198.0/25 *.microsoftonline-p.com
157.56.58.0/25 *.microsoftonline-p.net
*.microsoftonlineimages.com
*.microsoftonlinesupport.net
(Only outbound ports 80 and 443)
For up to date information about other IP addresses and URLs associated with Office
365 services, see the following sites:
Microsoft Exchange Online

Exchange Online URLs and IP Address Ranges (http://help.outlook.com/en-
us/140/gg263350.aspx )
Microsoft SharePoint Online
SharePoint Online URLs and IP Address Ranges
(http://office.microsoft.com/en-us/sharepoint-online-enterprise-
help/sharepoint-online-urls-and-ip-addresses-HA102727826.aspx)
Forefront Online Protection for Exchange
Forefront Online Protection for Exchange Online URLs and IP Address Ranges
(http://technet.microsoft.com/en-us/library/hh510075.aspx)
Microsoft Lync Online
Lync Online URLs and IP Address Ranges (http://technet.microsoft.com/en-
us/library/hh372948.aspx)
Required Ports
Protocol /Port Applications
Active Directory Federation Services (federation server role)
Active Directory Federation Services (proxy server role)
Microsoft Online Services Portal
My Company Portal
Microsoft Outlook 2010 and Outlook 2007
Microsoft Entourage 2008 EWS/Outlook 2011 for Mac
Outlook Web App
SharePoint Online
TCP 443 Lync 2010 client (communication to Lync Online from on-
premises
Lync Server)
TCP 25 Mail routing
TCP 587* SMTP relay
TCP 143/993 Simple IMAP4 migration tool
TCP 995** POP3
TCP 80 and 443* Microsoft Online Services Directory Synchronization Tool
Simple Exchange Migration Tool
Simple IMAP Migration Tool
Staged Exchange Migration Tool
Exchange Management Console
Exchange Management Shell
PSOM/TLS 443 Lync Online (outbound data sharing sessions)

STUN/TCP 443 Lync Online (outbound audio, video, application sharing
sessions)
STUN/UDP 3478 Lync Online (outbound audio and video sessions)
RTC/UDP 50000- Lync Online (outbound audio and video sessions)
59999

*SMTP Relay with Exchange Online requires port 587(TCP) and requires TLS. For details
on how to configure this, see the help topic DNS Troubleshooting for Exchange Online at
http://help.outlook.com/140/dd875725.aspx.
SMTP Relay with Exchange Online. Note: you will need to provide the SMTP server
which is specific to the mailbox used for relay. See the TechNet article Set Up
Outlook 2007 for IMAP or POP Access to Your E-Mail Account at
http://technet.microsoft.com/en-us/exchangelabshelp/cc835669.
** POP3 access with Exchange Online requires port 995 TCP) and requires SSL. For
details on how to configure POP3 with Exchange Online, see the TechNet article Configure
POP for Exchange Online at http://technet.microsoft.com/en-us/library/ff535990.aspx.

Appendix C: External Document
References
Title Link
Office 365 for Enterprise Service http://www.microsoft.com/download/en/details.aspx?
Descriptions id=13602
Office 365 Frequently Asked http://www.microsoft.com/en-us/office365/faqs.aspx

Questions
Office 365 release notes http://community.office365.com/en-us/w/release-

notes/default.aspx
Office 365 Transition Checklist http://download.microsoft.com/download/A/6/4/A6479925-

C7D2-4C4C-A21B-48BCCF8887A9/Checklist_EN_191010.docx
BPOSS Service Descriptions http://www.microsoft.com/download/en/details.aspx?

Active Directory Synchronization http://onlinehelp.microsoft.com/en-us/office365-

Roadmap enterprises/ff652543.aspx
To Sign Up for an Office 365 Trial http://www.office365.com

Subscription
Using email on your Mobile http://onlinehelp.microsoft.com/en-us/office365-

Phone/Device Configuration enterprises/ff637599.aspx
Administration and http://onlinehelp.microsoft.com/en-us/Office365-enterprises

Troubleshooting: Enterprise
Online help:
Training Search Query http://www.bing.com/search?q=

%22office+365%22+training&qs=n&sk=&sc=8-12&form=QBRE
Using a CNAME record to Enable http://help.outlook.com/en-us/140/cc950655.aspx

Outlook to connect to Office 365
Add your domain to Office 365 http://onlinehelp.microsoft.com/en-us/office365-

enterprises/ff637620.aspx#bkmk_configure
Planning for Directory http://www.microsoft.com/online/help/en-us/helphowto/14e35777-

Synchronization ebf6-4cbc-a3ea-b5d600f78b4f.htm
Transition BPOS to Office 365:

Checklist for Administrators.
Note that this is the definitive
authoritative source for the
technical steps that are absolutely http://www.microsoft.com/online/help/en-us/helphowto/8939e90a-
required to successfully transition. 59dc-4f0f-aec0-19a899c0af75.htm
This list may change from time to
time and should be reviewed
throughout your pre-transition
phase.
To Configure Outlook Anywhere http://technet.microsoft.com/en-us/library/cc179036.aspx

Title Link
for Exchange 2010
To Configure Outlook Anywhere http://technet.microsoft.com/en-us/library/cc179036(office.12).aspx

for Exchange 2007
For information on Office 2007 http://office.microsoft.com/en-us/training-FX101782702.aspx?CTT=97

and Office 2010 Training
SharePoint Online for Office 365: http://www.microsoft.com/download/en/details.aspx?id=17069

Developers Guide.
Mobile Phone Setup Wizard http://help.outlook.com/en-us/140/dd936215.aspx
Live Meeting-to-Lync Transition http://technet.microsoft.com/en-us/lync/hh182968

Guide
Transition Planning Resources
Live Meeting Transition Support http://www.livemeeting.com/ask
Single sign on: roadmap http://onlinehelp.microsoft.com/en-us/office365-

enterprises/hh125004.aspx
DNS Troubleshooting for http://help.outlook.com/beta/dd875725.aspx
Exchange Online
Setup Outlook 2007 for IMAP or http://technet.microsoft.com/en-us/exchangelabshelp/cc835669

POP access to your email account
Configure POP for Exchange http://technet.microsoft.com/en-us/library/ff535990.aspx

Online
Company Network Requirements http://technet.microsoft.com/library/cc745931.aspx
Defining Your Requirements for http://technet.microsoft.com/library/gg398341.aspx

Conferencing
About administering your account http://onlinehelp.microsoft.com/en-us/office365-

enterprises/ff637579.aspx
Understanding Role Based http://g.microsoftonline.com/0BD00en-US/250

Access Control
Plan Visual Upgrade (SharePoint http://technet.microsoft.com/en-us/library/ff191199.aspx

Server 2010)
Plan for directory synchronization http://onlinehelp.microsoft.com/en-us/Office365-

enterprises/16ca22da-e9e4-4f14-90aa-
24e480479073#BKMK_EnableDirectorySynchronization
Synchronize your directories

http://onlinehelp.microsoft.com/en-us/Office365-
enterprises/ff652557.aspx
IP addresses and URLs used by http://onlinehelp.microsoft.com/en-us/Office365-
Office 365 enterprises/hh373144.aspx
Exchange Online URLs and IP http://help.outlook.com/en-us/140/gg263350.aspx

Title Link
Address Ranges
SharePoint Online URLs and IP http://office.microsoft.com/en-us/sharepoint-online-enterprise-

Address Ranges help/sharepoint-online-urls-and-ip-addresses-HA102727826.aspx
Forefront Online Protection for http://technet.microsoft.com/en-us/library/hh510075.aspx

Exchange Online URLs and IP
Address Ranges
Lync Online URLs and IP Address http://technet.microsoft.com/en-us/library/hh372948.aspx

Ranges
Download the Office Live Meeting http://office.microsoft.com/en-us/help/download-the-microsoft-office-
2007 Client live-meeting-2007-client-HA010173383.aspx

Appendix D: Glossary of Terms
Active Directory Federation Services (AD FS): AD FS provides the various end-
points that the Microsoft Federation Gateway uses to redirect clients to the AD FS
server for different types of authentication. AD FS must be installed on a separate
physical server that is a part of your on-premises network organization.
Autodiscover: The Exchange Autodiscover service automatically finds the correct
Microsoft Exchange Server host and configures Microsoft Office Outlook for your
users. It also includes an offline address book and the Free-Busy availability service
that provides availability information for your users.
BPOS (Business Productivity Online Standard Suite): This is the acronym for
the first version of the cloud-based, multi-tenant productivity suite from Microsoft
Online Services. The BPOS service offering is being replaced by Office 365 service
offerings.
Comma separated value (CSV) file: A text file in which each value is separated
by a comma. It is typically used as an input file for a software program or script.
CNAME record: A Canonical Name (CNAME) record is a type of resource record in
the Domain Name System (DNS) that is an alias for the Address (A) record that
maps an IP address to the target server. The target server does not have to exist in
the same domain as the CNAME record itself. You can define an alias in one domain
to point to a target server in a completely different domain. Many organizations use
CNAME records with web servers. An organization might point the alias www to a
Web server that is hosted by a dedicated Web hosting company. For example,
requests for www.contoso.com can be redirected to webserver1.fabrikam.com
Directory synchronization: Active Directory synchronization replicates an
organizations on-premises Active Directory information for mail-enabled objects to
the Office 365 environment. Using the Microsoft Online Services Directory
Synchronization Tool, your companys administrators can keep your local Active
Directory continuously synchronized with Office 365.
Domain registrar: A domain name registrar is an organization or commercial
entity, accredited by the Internet Corporation for Assigned Names and Numbers
(ICANN) or by a national country code top-level domain (ccTLD) authority, to
manage the reservation of Internet domain names in accordance with the guidelines
of the designated domain name registries and offer such services to the public.
Exchange Management Shell: The command-line interface for Exchange 2010.
Exchange Control Panel (ECP): This Web-based console is used to manage the
Exchange Online environment. The ECP can be accessed through the Admin area of
the Microsoft Online Services Portal.
Exchange Hosted Archive: Part of the Exchange Hosted Services (EHS) network,
EHA provides a repository that stores email. Using EHA, organizations can manage
increasingly complex retention, compliance, and regulatory requirements. The EHA
systems receive a message and after being filtered the clean message is delivered
to the corporate mail server. A copy is made and stored in a security-enhanced
online message repository.

Exchange Online: A hosted email and messaging service built on Microsoft
Exchange Server and offered by Office 365. For organizations using on-premises
Exchange Server and Exchange Online, Exchange Online is sometimes referred to as
the cloud-based Exchange organization.
External relay: A configuration option in Microsoft Online Services Portal when
mailboxes for a domain are hosted outside of Exchange Online and the MX record
points to an email server outside of Exchange Online. Selecting this option requires
disabling of inbound messaging.
FOPE Administration Center: The service management site for Microsoft
ForeFront Online Protection for Exchange.
Identity federation: Identity federation provides a true single sign-on (SSO)
experience for users to access both the on-premises and Office 365 service
offerings with a single user name and password. Additionally, identity federation
allows administrators to easily control account policies for Office 365 mailboxes by
using on-premises Active Directory management tools and control access to Office
365 from various network locations (e.g. corporate network vs. outside internet).
Internet Message Access Protocol (IMAP): This is an application-layer Internet
standard protocol used by on-premises email clients to retrieve email from a remote
server over a TCP/IP connection. Microsoft Online supports email data migration
from IMAP4 environments, and access to Exchange Online mailboxes via IMAP
protocol.
Journaling: A feature of Office 365 that enables Exchange to record all email
communications in an organization. The feature can be enabled by opening a
service request with the support team.
Lync Online: The Office 365 solution for instant messaging, audio and video
calling, and online meetings. The Lync Online service is built on Microsoft Lync 2010
Server.
Microsoft Forefront Online Protection for Exchange (FOPE): FOPE consists of
layered technologies to actively help protect your organizations inbound and
outbound email from spam, viruses, phishing scams, and email policy violations.
Microsoft Online Services Module for Windows PowerShell: This tool installs
a set of cmdlets to Windows PowerShell that you use to set up single sign-on for
Office 365.
Microsoft Online Services ID: When you first sign up for Microsoft Office 365, you
create a new email address and password, known as a Microsoft Online Services ID,
as part of the sign-up process. You use this email address and password every time
you sign in to use Microsoft Office 365 service offerings. With your Microsoft Online
Services ID, you sign in to perform administrative tasks, view billing and account
information, and use any of the services, including Microsoft Exchange Online,
Microsoft SharePoint Online, and Microsoft Lync Online.
Microsoft Online Services Portal: Web portal that the designated service
administrator for a customer subscribing to Microsoft Online Services uses to
manage settings for the organization. You can also manage your active
subscriptions: for example, you can increase the number of user licenses, change
billing details, or select a Microsoft Authorized Partner to help with your subscription

MX record: A mail exchanger record (MX record) is a type of resource record in the
Domain Name System that specifies a mail server responsible for accepting email
messages on behalf of a recipient's domain and a preference value used to prioritize
mail delivery if multiple mail servers are available.
Office 365 desktop setup package: This application is installed on workstations
that use rich clients (such as Microsoft Office 2010) and connect to Office 365
service offerings. It automatically configures rich clients for use with Office 365 and
manages and installs client updates.
Office Professional Plus: Microsoft Office applications that connect to Office 365
service offerings and provide access to documents, email, and calendars from a
variety of clients. Office Professional Plus includes Office Web Apps, online
companions to Word, Excel, PowerPoint, and OneNote, which let you review and
make light edits to documents directly from a browser.
Office Web Apps. Online companions to Word, Excel, PowerPoint, and OneNote,
which let you review and make light edits to documents directly from a browser.
Outlook Web App: This is the browser-based email client used to access Exchange
Online. It was formerly known as Outlook Web Access.
Remote PowerShell: A Windows PowerShell feature that allows scripting of routine
tasks and access to raw data for reports.
Service continuity: The process and procedures required to maintain or recover
critical services during a business interruption.
Service interruption: Any event, whether anticipated (for example, a public
service strike) or unanticipated (for example, a power outage), which disrupts the
normal course of business operations at the organizations location. Similar terms:
outage, service interruption.
SharePoint Online: The Office 365 solution for collaboration. The SharePoint
Online service is built on Microsoft SharePoint Server 2010.
Single-label domain (SLD): SLDs are DNS names that do not contain a suffix,
such as .com, .corp, .net, or .org. SLDs are not supported in Office 365 and
Exchange Online deployments. For example, contoso is an SLD, and therefore is
not supported. However, contoso.com is not an SLD, and therefore is supported.
Single sign-on: See Identity Federation.
SMTP relay: Allows organizations to use Exchange Online as an SMTP service for
mail originating outside of the Exchange Online environment, for example SMTP-
enabled applications such as fax servers.
SPF record: The Sender Policy Framework (SPF) record specifies which computers
are authorized to transmit email from a domain. This helps to prevent others from
using your domain to send SPAM or other malicious email. If your ISP has
implemented SPF, you must create an SPF record to allow Microsoft Exchange
Online to send email from your domain.
User Principal Name (UPN): A user account name (sometimes referred to as the
user logon name) and a domain name identifying the domain in which the user
account is located. This is the standard usage for logging on to a Microsoft Windows
domain. The format is [email protected] (similar to an e-mail address). Office

365 requires the UPN and at least one SMTP address for the associated user to
precisely match.
User Principal Name (UPN) suffix: The part of the UPN to the right of the @
character. The default UPN suffix for a user account is the Domain Name System
(DNS) domain name of the domain that contains the user account. Alternative UPN
suffixes may be added to simplify administration and user logon processes by
providing a single UPN suffix for all users. The UPN suffix is used only within the
Active Directory forest, and it does not have to be a valid DNS domain name.

Office365 Enterprise Transition Guide en v2.2

Uploaded by

Copyright:

Available Formats

Office365 Enterprise Transition Guide en v2.2

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Office365 Enterprise Transition Guide en v2.2

Uploaded by

Copyright:

Available Formats

BPOSS to Office 365 Transition

Transition Planning Guide for Enterprises

Published: July 2012

BPOS-S to Office 365 Transition Planning Guide for Enterprises 2

Section 2: Transition Tasks and Timeline................................................17

BPOS-S to Office 365 Transition Planning Guide for Enterprises 3

Section 3: Technical Considerations.......................................................41

BPOS-S to Office 365 Transition Planning Guide for Enterprises 4

Section 4: Client Experiences................................................................61

BPOS-S to Office 365 Transition Planning Guide for Enterprises 5

BPOS-S to Office 365 Transition Planning Guide for Enterprises 6

Overview of the Transition

BPOS-S to Office 365 Transition Planning Guide for Enterprises 7

How Office 365 Services Map to BPOS

How to Use this Guide

BPOS-S to Office 365 Transition Planning Guide for Enterprises 8

Document Scope and Limits

BPOS-S to Office 365 Transition Planning Guide for Enterprises 9

Customer Environment Assumptions

BPOS-S to Office 365 Transition Planning Guide for Enterprises 10

BPOS-S to Office 365 Transition Planning Guide for Enterprises 11

BPOS-S to Office 365 Transition Planning Guide for Enterprises 12

BPOS-S to Office 365 Transition Planning Guide for Enterprises 13

BPOS-S to Office 365 Transition Planning Guide for Enterprises 14

o Microsoft Exchange Server 2010, Exchange Server 2007, or Exchange

o Microsoft Live Meeting

o DNS and related technologies

o Windows PowerShell 2.0

o Internet Information Services ((IIS) 6 or higher

Knowledge and proficiency in the following Microsoft client technologies:

o Microsoft Office 2010 and Office 2007

o Windows Internet Explorer 7 or higher and other Internet browser

BPOS-S to Office 365 Transition Planning Guide for Enterprises 15

BPOS-S to Office 365 Transition Planning Guide for Enterprises 16

BPOS-S to Office 365 Transition Planning Guide for Enterprises 17

BPOS-S to Office 365 Transition Planning Guide for Enterprises 18

BPOS-S to Office 365 Transition Planning Guide for Enterprises 19

User and Administrator Impact During the Transition

BPOS-S to Office 365 Transition Planning Guide for Enterprises 20

BPOS-S to Office 365 Transition Planning Guide for Enterprises 21

BPOS-S to Office 365 Transition Planning Guide for Enterprises 22

BPOS-S to Office 365 Transition Planning Guide for Enterprises 23

BPOS-S to Office 365 Transition Planning Guide for Enterprises 24

BPOS-S to Office 365 Transition Planning Guide for Enterprises 25

BPOS-S to Office 365 Transition Planning Guide for Enterprises 26

Transition Phases and Milestones

BPOS-S to Office 365 Transition Planning Guide for Enterprises 27

BPOS-S to Office 365 Transition Planning Guide for Enterprises 28

Pre-Transition Phase Key Activities

BPOS-S to Office 365 Transition Planning Guide for Enterprises 29

BPOS-S to Office 365 Transition Planning Guide for Enterprises 30

BPOS-S to Office 365 Transition Planning Guide for Enterprises 31

Office 365 Transition Phase

BPOS-S to Office 365 Transition Planning Guide for Enterprises 32

Office 365 Transition Phase Key Activities

Office 365 Post-Transition Phase

Post-Transition Phase Key Activities

BPOS-S to Office 365 Transition Planning Guide for Enterprises 33

BPOS-S to Office 365 Transition Planning Guide for Enterprises 34

(Earlier than T-60 Days) to Transition