migrating lotus notes applications to microsoft oœ ce 365 and

WHITE PAPER

Author

Steve WalchSenior Product Manager

Quest Software

Migrating Lotus Notes Applications to

Microsoft O� ce 365 and SharePoint Online

White Paper: Migrating Lotus Notes Applications to Microsoft Office 365 and SharePoint Online 1

© 2011 Quest Software, Inc.

ALL RIGHTS RESERVED.

This document contains proprietary information protected by copyright. No part of this document may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying and recording, for any purpose without the written permission of Quest Software, Inc. (“Quest”).

The information in this document is provided in connection with Quest products. No license, express or implied, by estoppel or otherwise, to any intellectual property right is granted by this document or in connection with the sale of Quest products. EXCEPT AS SET FORTH IN QUEST'S TERMS AND CONDITIONS AS SPECIFIED IN THE LICENSE AGREEMENT FOR THIS PRODUCT, QUEST ASSUMES NO LIABILITY WHATSOEVER AND DISCLAIMS ANY EXPRESS, IMPLIED OR STATUTORY WARRANTY RELATING TO ITS PRODUCTS INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT. IN NO EVENT SHALL QUEST BE LIABLE FOR ANY DIRECT, INDIRECT, CONSEQUENTIAL, PUNITIVE, SPECIAL OR INCIDENTAL DAMAGES (INCLUDING, WITHOUT LIMITATION, DAMAGES FOR LOSS OF PROFITS, BUSINESS INTERRUPTION OR LOSS OF INFORMATION) ARISING OUT OF THE USE OR INABILITY TO USE THIS DOCUMENT, EVEN IF QUEST HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. Quest makes no representations or warranties with respect to the accuracy or completeness of the contents of this document and reserves the right to make changes to specifications and product descriptions at any time without notice. Quest does not make any commitment to update the information contained in this document.

If you have any questions regarding your potential use of this material, contact:

Quest Software, Inc.

Attn: Legal Department

5 Polaris Way

Aliso Viejo, CA 92656

www.quest.com

email: [email protected]

Refer to our Web site for regional and international office information.

Trademarks

Quest, Quest Software, the Quest Software logo, AccessManager, ActiveRoles, Aelita, Akonix,

AppAssure, Benchmark Factory, Big Brother, BridgeAccess, BridgeAutoEscalate, BridgeSearch,

BridgeTrak, BusinessInsight, ChangeAuditor, ChangeManager, Defender, DeployDirector, Desktop

Authority, DirectoryAnalyzer, DirectoryTroubleshooter, DS Analyzer, DS Expert, Foglight, GPOADmin,

Help Desk Authority, Imceda, IntelliProfile, InTrust, Invirtus, iToken, I/Watch, JClass, Jint, JProbe,

LeccoTech, LiteSpeed, LiveReorg, LogADmin, MessageStats, Monosphere, MultSess, NBSpool,

NetBase, NetControl, Npulse, NetPro, PassGo, PerformaSure, Point,Click,Done!, PowerGUI, Quest

Central, Quest vToolkit, Quest vWorkSpace, ReportADmin, RestoreADmin, ScriptLogic, Security Lifecycle

Map, SelfServiceADmin, SharePlex, Sitraka, SmartAlarm, Spotlight, SQL Navigator, SQL Watch, SQLab,

Stat, StealthCollect, Storage Horizon, Tag and Follow, Toad, T.O.A.D., Toad World, vAutomator,

vControl, vConverter, vFoglight, vOptimizer, vRanger, Vintela, Virtual DBA, VizionCore, Vizioncore

vAutomation Suite, Vizioncore vBackup, Vizioncore vEssentials, Vizioncore vMigrator, Vizioncore

vReplicator, WebDefender, Webthority, Xaffire, and XRT are trademarks and registered trademarks of

Quest Software, Inc in the United States of America and other countries. Other trademarks and registered

trademarks used in this guide are property of their respective owners.

http://www.quest.com/

mailto:[email protected]


Contents Abstract ......................................................................................................................................................... 4

Introduction.................................................................................................................................................... 5

Pre-Migration Analysis .................................................................................................................................. 6

Step 1: Discover All of Your Notes Databases .......................................................................................... 6

Step 2: Determine What You Don’t Have to Migrate ................................................................................. 7

Step 3: Understand the Complexity of Your Applications .......................................................................... 7

Step 4: Consolidate Similar Application Designs ....................................................................................... 8

Step 5: Formulate Your Migration Plan ...................................................................................................... 9

Migrating Notes Application Content ........................................................................................................... 10

Lists, Libraries and Pages ....................................................................................................................... 10

Lists ...................................................................................................................................................... 10

Libraries ............................................................................................................................................... 10

Pages ................................................................................................................................................... 11

Migrating Content to Standard Lists ........................................................................................................ 11

Migrating Content to Custom Lists ........................................................................................................... 12

Migrating to Document Libraries .............................................................................................................. 14

Generating Documents ............................................................................................................................ 15

Microsoft Word ..................................................................................................................................... 15

PDF ...................................................................................................................................................... 16

InfoPath ................................................................................................................................................ 17

Using Document Sets .............................................................................................................................. 19

Migrating Content to SharePoint Pages .................................................................................................. 20

Wiki Pages ........................................................................................................................................... 20

Web Part Pages and Publishing Pages ............................................................................................... 21

Archiving Legacy Content: Document Rendering .................................................................................... 21

Migrating Application Designs ..................................................................................................................... 23

Migrating Schema from Notes Applications ............................................................................................. 23

Migrating Form Designs to InfoPath ........................................................................................................ 24

Migrating Approval Process and Workflow State .................................................................................... 25

Deploying Sandbox Solutions .................................................................................................................. 26

Understanding the Limitations of Office 365 .............................................................................................. 27

Connecting to Enterprise Data ................................................................................................................. 27


Mail-In Databases .................................................................................................................................... 27

Deploying Custom Code .......................................................................................................................... 28

Standard Server Settings ......................................................................................................................... 28

Bandwidth and Throttling ......................................................................................................................... 28

Other “Missing” Features ......................................................................................................................... 29

Conclusion................................................................................................................................................... 30

Appendix A - SharePoint Online Deployment Basics ................................................................................. 31

Getting Started ......................................................................................................................................... 31

Choosing the Right Office 365 Plan ......................................................................................................... 32

Basic Tenant Administration .................................................................................................................... 33

Adding Users and Synchronizing Directories .......................................................................................... 34

Provisioning and Managing Site Collections ........................................................................................... 35

Building your SharePoint Sites ................................................................................................................ 36

About the Author ......................................................................................................................................... 37


Abstract This white paper explores the process of migrating Lotus Notes applications to SharePoint Online, which

is part of Microsoft Office 365. It examines issues related to pre-migration analysis, content migration,

security migration, application design, SharePoint Online deployment options, and Office 365 limitations

likely to affect Notes migrations.


Introduction Many long-standing Lotus Notes customers have already made the switch to Microsoft Exchange for their

mail and calendaring needs and to Microsoft SharePoint for their team rooms, discussions, document

libraries, and many custom applications. While this exodus off of Notes has been happening over the past

decade, it has become more of a stampede over the last two years. Microsoft’s new online platform,

Office 365, has helped accelerate this change.

Notes customers are particularly excited about Office 365 for a number of reasons:

Having Microsoft host your collaboration infrastructure represents a huge cost-of-ownership savings for organizations that don’t want to deploy and manage internal mail and application servers. You don’t have to invest in hardware and software up front or maintain a large IT staff to keep everything up and running.

While the predecessor to Office 365, the Business Productivity Online Suite (BPOS), was pretty good for mail and calendaring, the SharePoint component had limited capabilities, and migration of legacy content was severely restricted. Many Notes customers who wanted to move applications to SharePoint have been waiting for this generation of online technology.

Office 365 is based on Office 2010, which offers a large number of platform improvements. SharePoint 2010 in particular includes many new capabilities that will reduce the cost of migrating (and sometimes rebuilding) custom Notes applications.

1

Office 365 gives instant global reach to both desktops and mobile devices. One of the big reasons Notes was so popular in its heyday was its support for replicating data among occasionally connected global servers. Today, bandwidth and connectivity issues are mostly a thing of the past, and organizations worldwide enjoy real-time access without the cost and headaches of replication.

Microsoft’s guarantee of 99.9% scheduled uptime is significantly better than most many organizations can realistically hope to achieve on their own. Microsoft not only runs the application and database servers, but also takes responsibility for redundant data centers and automatic failover.

This white paper explores the process of migrating Notes applications to SharePoint Online, which is

part of Office 365. It examines issues related to pre-migration analysis, content migration, security

migration, application design, and SharePoint Online deployment options, as well as describes Office

365 limitations that are likely to affect Notes migrations.

1 For more information, see the related white paper, “Ten Ways SharePoint 2010 Will Impact Your Notes Migration.”

http://www.quest.com/documents/landing.aspx?id=12162&prod=352


Pre-Migration Analysis Before migrating your Notes applications to SharePoint, you will want to take careful stock of your current

application environment. How many Notes databases do you have and which will be appropriate to move

to SharePoint Online? Which databases have not been used in several years and which contain data that

is still valuable to the organization? Which applications will translate easily to standard SharePoint

templates and which will require a significant amount of custom configuration or development?

Many organizations don’t have a ready answer to these questions, which makes it difficult to estimate the

timeframes and cost of the transition. There are several quality tools available to help with this process,

including some free ones, and most organizations will benefit from using these tools for at least a portion

of the process.

Step 1: Discover All of Your Notes Databases

The first step in a pre-migration analysis is to inventory all of the Notes applications across all of your

Notes/Domino servers. A good analysis tool will make this step easy, and it will also help you discover

which databases have been replicated across multiple servers. The tool should also be able to quickly

classify which databases were based on standard Notes application templates (discussion databases,

document libraries, calendars, contact lists, team rooms, QuickPlaces, etc.) and even start classifying all

the custom applications as well.

Depending on your needs, you may also want to scan the composition of the various databases to

determine how big they are, which ones have large attachments, who has access to them, which contain

lots of document links or embedded objects, who the content authors are, and so on. It is easy to imagine

a great variety of interesting reports that you might want to create from all of this data, so choose a tool

that enables you to export the data for use in Microsoft Excel or your favorite reporting tool.

Figure 1. Quest Notes Migrator for SharePoint discovers all the databases on your Notes/Domino servers.


When you embark on this step of the pre-migration analysis, make sure that you have access to all the

Notes/Domino servers you want to consider for migration. Performing the types of database analysis

described above should require only “Reader” level access to the individual Notes databases, but even

that may be hard to arrange in certain organizations, so be sure to plan ahead.

Step 2: Determine What You Don’t Have to Migrate

Once you have scanned your Notes environment, you should also be able to immediately eliminate

Domino administration, documentation and mail databases that most likely shouldn’t be migrated to

SharePoint.

Also, most organizations establish a policy that databases not used within a certain period of time

(perhaps two years) do not need to be migrated. Therefore, it is important that your analysis tool does a

good job of analyzing your databases’ usage patterns. This needs to be more sophisticated than just

looking at the “last used” date in the database header, since it is all too easy for an administrator or

automated task to reset this date. To get a true picture of usage, the tool must ignore those distortions

and focus on activity from real end users only. Finally, it is important to look across all replicas of a given

database and aggregate usage information.

In addition to excluding Domino-specific and unused databases, many organizations also manually

investigate which applications really deserve to be migrated, using the services of a business analyst or

even a systematic survey of the actual end users. You may discover cases where you need to archive old

content in SharePoint, but you no longer need the application functionality. Tools can help manage this

“rationalization” process and record the results, but some human intervention is definitely required here.

Ultimately, the more databases you can eliminate from the migration project, the more energy you can

devote to the important ones and the greater the likelihood that your project will come in on time and

within budget.

Step 3: Understand the Complexity of Your Applications

The complexity of your applications will significantly impact the cost and timing of your migration. Some

applications may map nicely to standard SharePoint templates; some may require a modest level of

customization such as replicating your old data schema or enabling a few checkbox features; and some

will require more in-depth migration of forms, views or workflow design.

Your analysis tool should help you analyze the complexity of your applications. Most tools can count the

number of forms, agents, and other design elements in order to give you a preliminary estimate of design

complexity. Some tools even attempt to estimate the number of hours that will be required to migrate

each application or recommend the appropriate migration targets.

Be aware that these are just rough estimates; you should not be making final decisions (or establishing

rigid budgets) based solely on machine analysis. With the exception of standard templates, a manual

assessment should be performed by experienced analysts. A good tool will support the manual analysis

and make it easy to adjust the tool-calculated numbers for accuracy.

Also, be careful not to assume that “complex” automatically means “hard to migrate.” There are many

cases in which a Notes database looked complex in Domino Designer but was easily replaced by existing

site templates or implemented with out-of-the-box SharePoint features. Of course, an organization’s

willingness to compromise and do things the SharePoint way can make a big difference here.


For example, organizations often have old Notes applications that no longer need all of the functionality

built in by the original Notes developer. Many simply need to be neatly archived in SharePoint. A good

migration tool can “render” complex documents with their original Notes forms to create rich text

documents that can be easily stored in standard SharePoint lists and libraries. This is discussed in

more detail in the section “Migrating Content to SharePoint Pages” below.

In addition to design complexity, migration teams should also take data complexity into account. Knowing

which Notes databases contain lots of doclinks, images, embedded objects, document-level access

restrictions, and so on can be very helpful in planning your migration process. It is very useful, for

example, to know which file attachments will be blocked by SharePoint due to restricted file extensions or

size limits before you begin the migration.

Step 4: Consolidate Similar Application Designs

The next step of your pre-migration analysis is to dig into the application designs. As described above,

standard applications can be easily recognized by tools and classified accordingly. The more challenging

aspect is to figure out what to do with all of the custom applications.

If you have many custom applications, one of the best things you can do is to identify the cases where

multiple Notes databases share the same design (or even a similar design). It was quite common in the

Notes world to either base many applications on a shared design template, or to simply copy the design

of existing databases and add a few customizations. The value of discovering these cases is that you can

greatly reduce the number of unique application designs you need to understand and migrate. This can

give you many opportunities to reuse migration jobs, custom development work and testing.

Identifying opportunities to consolidate application designs may be as simple as finding applications that

inherit the same Notes design template, or it may require actually scanning the design of the databases

for similarities. Your analysis tool should be able to help you with both of these tasks and should also

allow for manual classification of applications.


Figure 2. Notes Migrator for SharePoint compares the design of each database to assist with application design consolidation

Step 5: Formulate Your Migration Plan

Most organizations consider formulating a migration plan to be part of the analysis process. Once you

understand which applications you want to migrate and have identified places where you can consolidate

similar designs, the next step is to decide how things should be structured in SharePoint.

At a high level, your migration plan will include a design for the organization of SharePoint site collections

and sub-sites. Considerations at this level include:

Ease of navigation by users – The hierarchy of sites and sub-sites should make sense to the business.

Establishment of good security boundaries – Each site collection has its own set of administrators. It is easier to manage access rights if you can use the natural inheritance of permissions from sites to sub-sites rather than specify explicit permissions at lower levels.

SharePoint Online size limits – Current limits for Enterprise offerings include 100 GB per site collection and 300 site collections per account. Microsoft also publishes a number of best practices for sizing sites, lists, groups and members.

The timing of your migration – In many cases, it makes sense to migrate and validate a particular set of Notes applications together; therefore, it may be convenient to locate those applications close to each other in SharePoint.

At a lower level, your migration plan will include selecting site templates, selecting list and library

templates, and organizing lists and libraries within your sites. Many organizations find that the standard

SharePoint templates are more than adequate for migrating the bulk of their Notes applications. Others

will need special configuration or custom development.

Finally, your migration plan should include orchestrating what will be migrated when. Be sure to allow

time for any needed SharePoint customization or development, as well as any user acceptance testing

and training. The actual content migration time can vary widely depending on the bandwidth of connecting

to your Domino servers and the SharePoint Online servers.


Migrating Notes Application Content There are two main aspects to application migration: migrating application content and migrating

application design. We will focus on migrating content first for several reasons.

Correct content migration is often considered the most business critical aspect of the migration process. You can always tweak the design of an application later, but if you fail to preserve the legacy content with adequate fidelity and completeness, your users may be very unhappy.

Some legacy content is very sensitive for compliance reasons or other business reasons, so the stakes are very high to get both the content and access permissions right.

In many cases, there is no need for design migration. You simply migrate the old content into one of the new SharePoint site or list templates and you’re done.

In some cases, you will want to take the time to rethink the application design to take advantage of all the great new features of SharePoint Online. This would also eliminate the need for a design migration.

Lists, Libraries and Pages

There are three basic ways to store content in SharePoint: lists, libraries, and pages. Each of these has a

number of interesting variations, but it is important to understand the differences between these three

fundamental types so you can best decide what you want to migrate to. Each type is described briefly

here; the sections that follow explain in detail how to migrate content to each.

Lists

Lists are similar to tables in a relational database. A list is a flat collection of data records (called items in

SharePoint) with a fixed set of data fields (called columns). Each data column has a fixed name and type.

For example, a customer list may have a Text column called “Customer Name,” a Date column called

“First Purchase Date,” and potentially dozens of other columns. One particularly interesting column type is

Rich Text (also known as a “Note” “Body” column); this is where one would typically store large amounts

of rich text. Lists can also have one or more binary attachments and may have one or more views, which

allow users to select and sort the items in various ways.

All of this should sound pretty familiar to Notes customers, because a list is actually the closest thing in

SharePoint to a Notes database. The biggest difference is that SharePoint lists are highly structured with

a fixed schema (like a relational database), whereas Notes databases can be very unstructured, with

every document having a different set of data items.

Libraries

Libraries are collections of binary files, such as images, Word documents, or audio clips. While lists and

libraries are very similar internally, the metaphor is very different: in a list, the document may contain

several binary file attachments; in a library, the binary file is the document. The emphasis in libraries is

the document management functionality, including versioning and check-in/check-out. As with lists,

libraries can have many additional data columns defined for capturing additional information about each

document.

In the Notes world, the closest thing to a SharePoint library is a Domino.Doc file cabinet. (Domino.Doc

was a popular document management system built on top of Notes.) Many organizations also built

custom Notes applications that attempt to implement document management functionality. Any time you

see a Notes application where the file attachment is “the document,” consider migrating it to a SharePoint

library. It is also common for Notes “team site” applications to have a document library section as part of

the overall application.


Pages

Pages are the building blocks of all SharePoint sites. These are the web pages you actually see in the

web browser every time you click on a link to view a site, open a document, enter some information, or do

just about anything else. Most people do not realize that the same pages that make up the sites

themselves can also be used as data documents. SharePoint actually allows you to create several types

of content pages, including basic pages, wiki pages, web part pages, and publishing pages. SharePoint

Online includes several nice publishing site templates that are designed to manage the authoring,

approval and display of rich text web pages.

While content pages have no exact equivalent in the Notes world, they can be a great way to migrate

certain types of Notes applications. Any time you see a Notes application in which the main intent was to

publish a library of rich text pages to a large number of users, consider migrating it to a SharePoint page

library or a publishing site. This includes the many Notes applications that implemented public web or

extranet sites.

Migrating Content to Standard Lists

Lotus Notes came with many standard application templates that were widely used (with or without

customization) by many customers, including discussion databases, calendars, task lists, team sites,

contact lists, and document libraries. Happily, in all these cases there is an out-of-the-box SharePoint

template designed for you by Microsoft to serve the same purpose. The user interfaces of these new

templates may be a little different, but all of the functionality should be there.

This means you can migrate the content to the right template and you are done! Any good migration tool

should understand how to map from the Notes version of a standard template to the equivalent

SharePoint version. For example, the following figure (as well as all of the illustrations throughout the

paper) was created using a high-end migration tool, Quest Notes Migrator for SharePoint, and shows the

default mapping from a Notes task list to a SharePoint task list, plus an example of a resulting SharePoint

document. The migration team did not have to do any special configuration or design of the new task list

on SharePoint.

Figure 3. Notes Migrator for SharePoint migrates content from a Notes task list to a SharePoint task list


Even this simple example illustrates many important issues to consider when migrating content and

choosing tools:

Your migration tool should give you a good set of defaults, but should be flexible to allow you to customize as needed.

Rich text fidelity is extremely important. Notes rich text documents created by end users can be very sophisticated, even if the database design is simple. Few tools on the market can handle nested tables, embedded objects, and other advanced rich text constructs in ways that will be satisfying to your end users.

Notes rich text documents may contain in-place images and attachments. Your migration tool should not only display these elements in-place in SharePoint, it should also be smart about how it handles attachments that are blocked by SharePoint Online (such as .exe files or files over 250 MB).

Notes rich text documents may contain “doc links” that cross-reference other Notes documents. Few tools correctly preserve links between documents in different databases, especially if they are migrated at different times.

Notes documents contain metadata such as Created By, Created Date, Last Modified By, and Last Modified Date. Most migration tools drop this metadata during migrations to Office 365, resulting in a major loss of business data.

Most Notes databases contain access control lists, which determine what specific users can do in a particular application. In addition, individual documents can contain access restrictions such as Readers lists and Authors lists. Access definitions may leverage groups in the Domino Directory as well as roles defined for the database. Preserving all this information correctly in SharePoint may be critical to a successful migration of sensitive data.

These issues are actually not limited to migrations to standard SharePoint templates. All of the issues

listed above may apply equally well to the other types of migrations discussed below.

Migrating Content to Custom Lists

Custom lists in SharePoint are just like lists based on standard templates, except that you define all the

data columns (and possibly other list settings). When migrating a custom Notes application to a custom

list, your main job is going to be to map all the fields in your Notes database to the columns in your

custom list.

There are two main scenarios you may encounter here:

In some cases, your job will be to provision a new custom SharePoint template that has all the important data fields that the old Notes application had, with the proper column names and data types. Your migration tool should help you quickly generate a SharePoint list schema that mirrors the schema of your Notes application, as discussed in the section “Migrating Application Designs” below.

In other cases, your SharePoint developers may have already designed a great new application to reproduce the functionality of the old Notes application using new SharePoint constructs. In this case, your job is going to be to map one to the other. If you have built a custom SharePoint template, the migration tool should also be able to use it when provisioning new lists.


The following figure shows the mapping of many fields in a custom Notes application to a custom list in

SharePoint, plus an example of a resulting SharePoint document:

Figure 4. Notes Migrator for SharePoint migrates content from a custom Notes application to a SharePoint custom list

When migrating to custom lists, you can use any of a number of powerful SharePoint 2010 options:

SharePoint offers over a dozen data column types, including User, Boolean, Choice, and Lookup columns. Make sure you have a good understanding of these column types and use them in your migrations as appropriate.

Managed Metadata columns are a powerful new column type that allows you to draw from terms in a centralized term store. These column types support term hierarchies, aliases and translations. Few migration tools support them well, so be sure to understand in advance whether your migration team will want to use them. In particular, the tool should be able to automatically add new terms to the term store as they are encountered in migrated content.

Mapping the Notes schema to a SharePoint schema may be as simple as doing a one-to-one field mapping, but in more complex cases you may need to significantly transform the data between the two systems. A sophisticated migration tool will allow you to write formulas, perform lookups, and apply other data transformation techniques.

If you want to enable the standard approval process functionality in your SharePoint list, your migration tool will need to be able to map whatever mechanism was used to express approval status in your custom application to the equivalent SharePoint functionality.


If you want to mix multiple document types in one list, you may need to define content types. Your migration tool should be able to assign the appropriate content type to each document as it is migrated.

You can design multiple views for your lists that select, sort, categorize and subtotal information in different ways.

If the default single-column form that SharePoint generates for you (as shown in the figure above) is not good enough, you may need to design a custom form. This is discussed in more detail below.

If you have many Notes applications that share a similar design, your migration tool should support the reuse of both your migration job and your list design work in SharePoint.

Migrating to Document Libraries

From the perspective of a migration specialist, a library is very similar to a list. The main difference is that

in a library, each “document” is an actual binary file with various data properties associated with it.

Therefore, migrating a Notes database to a library typically involves extracting binary file attachments out

of each Notes document and placing them in the library. This really makes sense only if the Notes

application itself was designed to manage binary files—that is, if each Notes document is really just a

wrapper around a binary file attachment.

Below we have extracted the attachments from each Notes document and placed them in a document

library. You can also use Notes Migrator to extract various metadata items about each document and

map them to SharePoint properties.

Figure 5. Notes Migrator for SharePoint migrates content to a SharePoint library

Be aware that several things can go wrong with this type of migration job. If there are no attachments in a

particular Notes document (i.e., if it is just a normal rich text document), nothing will be migrated to the

library. If there are multiple attachments in a particular Notes document, they may all be migrated to the

library but they will no longer be one self-contained document. In either case, you have probably

misinterpreted the way the Notes application was used, and it should not have been migrated to a library

in this manner. Even if it was called a “document library” in Notes, it may be more appropriate to map it to

a custom list in SharePoint.


Additional considerations for migrating to SharePoint libraries include:

As stated above, Notes documents contain metadata such as Created By, Created Date, Last Modified By, and Last Modified Date. Many migration tools drop this metadata during migrations to Office 365, resulting in a major loss of business data.

Again, most Notes databases contain access control lists, which determine what specific users can do in a particular application. In addition, individual documents contain access restrictions such as Readers lists and Authors lists. Access definitions may use groups in the Domino Directory as well as roles defined for the database. Preserving all this information correctly in SharePoint may be critical to a successful migration of sensitive data.

If your Notes application has a concept of document versioning, make sure your migration tool allows you to correctly map the versioning to SharePoint versioning. All versions of a given document in Notes should appear to be versions of the same document in SharePoint.

It is common to want to assign folders during a migration. You should be able to dynamically generate folder names in SharePoint based on data extracted from Notes.

Instead of folders, you may want to use a powerful new SharePoint feature called Document Sets. This feature is discussed in more detail below in the section “Using Document Sets.”

Generating Documents

In addition to migrating file attachments to a SharePoint library, your migration tool may allow you to

generate new binary files to place in your library. Three very popular choices for migrating certain types of

documents are Microsoft Word, PDF, and InfoPath.

Microsoft Word

Microsoft Word is a popular choice in environments that have standardized on Microsoft Office for

document creation. The integration between Microsoft Office and SharePoint libraries is very good and

can enable you to build a variety of powerful applications. Users can open documents from libraries, edit

them and seamlessly save them back again. If a version control, check-in/check-out, or approval process

or workflow has been enabled for the library, it will all work automatically. Office clients even support

single sign-on with SharePoint and SharePoint Online.

Office documents in SharePoint libraries are easy to search and you can even generate an instant

SharePoint workspace to enable teams to collaborate on a particular document. Multiple users can open

the same Word document and edit it at the same time, and users can see the changes being made by

other users almost instantly.

When migrating Notes documents to the Microsoft Word format, you should be able to migrate to simple

unadorned documents or to custom Word templates. You should also be able migrate Notes data items to

Word document properties or even to content controls in your custom template.


The following figure shows a Notes rich text document that was converted to a Word document on a

custom letterhead template and checked into a SharePoint document library:

Figure 6. Notes Migrator for SharePoint converts a Notes document to a Word document in a SharePoint library

PDF

PDF is another popular choice for migrating rich text Notes documents. Many organizations, especially in

Europe, use PDFs to archive old content. Since PDF is now an open standard, the assumption is that

there will always be a PDF reader such as Adobe Acrobat available in the future. An organization that has

a large number of Notes databases with rich text documents may find that PDF is an ideal target format

for many of them.

When PDF documents are placed in a SharePoint library, the integration is not quite as tight as it is with

Office applications, but the user experience is still reasonable. Even though PDF readers and editors are

not generally “SharePoint aware,” the experience of opening PDF documents is similar to downloading

them from any web site. PDF documents can work with SharePoint’s search features, but you need to

install a free add-on from Adobe for SharePoint’s full-text search indexer to read the content.


A word of warning about migration tools: a number of tools advertise the ability to convert Notes

documents to PDF documents, but deliver poor results. If you plan to use this feature, it is strongly

recommended that you test the tools with your user’s most complex documents. Watch for how nested

tables, embedded images, links to attachments and doc links are handled.

The following figure shows a Notes rich text document that was converted to a PDF document and

checked into a SharePoint document library:

Figure 7. Notes Migrator for SharePoint converts a Notes document to a PDF document in a SharePoint library

InfoPath

People sometimes choose the InfoPath document format when they want to migrate complex Notes

applications to SharePoint, usually for one of two reasons: either the applications have complex data

structures that do not lend themselves to being stored in a SharePoint List, or the applications have

complex form designs that contain dynamically hidden sections, input validation rules, buttons, form

events, or other sophisticated form logic. For these reasons, we will focus on the migration of Notes

content to InfoPath documents.

InfoPath data documents (traditionally called “InfoPath forms”) are really XML files that you edit using the

InfoPath client (part of Office) or perhaps in a browser if your SharePoint server is running InfoPath Form

Services. You specify the layout and behavior of your InfoPath form (and associate it with your desired

XML schema) by creating an InfoPath form template. Typically you would store your XML data documents

in a special type of SharePoint library known as a form library. This library is associated with one or more

form templates in such a way that end users get a fairly seamless experience of creating, viewing and

editing complex documents right from the library.


When performing a Notes migration, your main job is to convert Notes documents to InfoPath XML data

documents according to a particular XML schema and check them into a form library. A high-end

migration tool should make this fairly straightforward. All you need to do is load in an InfoPath form

template and specify how you want various Notes data elements to map to the various parts of your new

XML schema. These elements might include not only simple data fields, but also rich text, embedded

images and attachments, links to external attachments, and links to other documents. As XML schemas

are not necessarily one dimensional, you may need to map one-to-many data items as well (for example,

a product description document might contain multiple distributor names).

The following figure shows a Notes rich text document that was converted to an InfoPath document

(associated with a specific InfoPath form template) and checked into a SharePoint form library:

Figure 8. Notes Migrator for SharePoint converts a Notes document to an InfoPath document in a SharePoint library

In this discussion, we did not specify how the InfoPath form template was created. It may have been

created from scratch by your InfoPath developer or you may have migrated an existing Notes form using

a migration tool, which we will discuss in the section “Migrating Application Designs” below.


Using Document Sets

Document Sets are a great way to keep multiple related files together as one logical document group in a

SharePoint library. In many respects, one can think of a Document Set as a new, more powerful type of

folder. Documents in the same Document Set may be secured, approved and versioned together, and the

document set as a whole is displayed with a nice, customizable user interface. You can assign custom

properties to the Document Set as a whole, or to each document within the Document Set.

The following figure shows a document set named “Notes Migrator for SharePoint” that contains

six documents:

Figure 9. Sample Document Set containing six documents

There are two ways to think about migrating Notes content to Document Sets:

Map multiple Notes documents into the same Document Set. Typically you would use some Notes data item (for example: the Category field, the Product Name or the Binder fields) to define the Document Sets. In the figure above, “Notes Migrator for SharePoint” was actually a Domino.Doc binder name and the six files were the documents inside the binder.

Map each Notes document to a unique Document Set. Each attachment, image, or embedded object can now become a document inside the Document Set. In addition, you can map the rich Notes document itself to a document in the Document Set. The following figure shows a Word document that was generated to contain all the Notes rich text content, with all the attachments migrated as siblings inside the Document Set:


Figure 10. Notes Migrator for SharePoint migrates Notes rich text content and attachments to a Document Set

Migrating Content to SharePoint Pages

There are at least five ways to migrate Notes documents to web pages in SharePoint Online. Each of

these page types gives a slightly different editing experience for content authors and a slightly different

viewing experience for end users:

HTML pages

Basic pages

Wiki pages

Web part pages

Publishing pages

Wiki Pages

The wiki page is probably the most popular page type for migrating Notes content. The wiki page has

been greatly improved in SharePoint 2010 and is now central to the design of many SharePoint site

templates. For example, when you create a new “page” using the Create menu in a team site, you are

creating a wiki page.

Migrating Notes documents to wiki pages is very easy in a high-end migration tool. As with the Word and

PDF document generation examples shown above, you would typically map the rich text “Body” field to

the wiki page content area and map whatever additional Notes data items you wanted to preserve to

page properties.

The following figure shows a Notes rich text document that was converted to a wiki page and checked

into a SharePoint page library. Since images and attachments cannot be contained in a wiki page, these

elements were migrated to a separate library and then linked into the main page.


Figure 11. A Notes rich text document that was converted to a wiki page by Notes Migrator for SharePoint

Web Part Pages and Publishing Pages

Web part pages give you additional control over how elements are laid out in a web page, which may

consist of multiple web parts that you direct Notes content to Publishing pages implement a similar

concept, with a cleaner separation between the documents created by the content authors (or the

migration tool) and the visual layout and styling of the pages. Publishing solutions also typically include a

concept of checking content in and out, submitting it for approval, and managing the workflow for

publishing the content to the intended audience.

Archiving Legacy Content: Document Rendering

If you have a lot of Notes databases to migrate, a good number of them are likely no longer being actively

used to create new documents but still contain valuable reference data. With applications like that, you

don’t always want to invest time and energy to rebuild the forms and functionality. You simply want a

good way to archive the content in SharePoint so that it looks good and is searchable by users.

Earlier we showed how to extract rich text fields and convert them into Word documents, PDF documents,

wiki pages, and so on. In some cases, this is the perfect solution for archiving legacy content in

SharePoint. In other cases, this is not good enough because it does not capture the rich form layout that

Notes users are used to. Without the form layout, you really haven’t captured all the information.

This is where an advanced concept known as document rendering comes in. With this technique, the

migration tool “renders” each document with its original Notes form to generate a new rich text document

that includes the entire form layout you had in Notes. To visualize this, compare the generated PDF

document in the following figure with the PDF example provided earlier in Figure 7:


Figure 12. Using document rendering to capture the Notes form layout using Notes Migrator for SharePoint

In addition to the rich text body, we captured the information that was presented with the original Notes

form. Most significantly, we did not have to redevelop the form in SharePoint to accomplish this, nor did

we have to explicitly map all the data fields that are displayed in the form header.

We used PDF in this example, but the same concept of rendering documents with forms applies equally

well to Word documents, InfoPath documents, pages and even lists.


Migrating Application Designs Good tools are available today for migrating the content of your Notes applications to SharePoint, but

what about migrating the design? What about all the forms, views, agents, workflows, and so on? One of

the biggest barriers to moving large numbers of Notes applications to SharePoint is the cost of rebuilding

complex applications.

Unfortunately no migration tool allows you to press a button and magically reproduce the entire design of

a custom Notes application in SharePoint. As we will see in this section, there are certain aspects of

design migration where it makes sense to use a migration tool and others where it does not.

Migrating Schema from Notes Applications

As discussed above, one of your first tasks when migrating custom Notes applications is often to

provision a new custom SharePoint template that has the same important data fields as the old Notes

application, with the proper field names and data types.

Because a custom Notes application may have dozens or even hundreds of fields, it is fortunate that

high-end migration tools contain features that help you automate this task. This is typically a two-part

process of “deducing” the schema being used in a Notes application and then provisioning a similar

schema for SharePoint.

Why did we use the word “deduce” above? Unfortunately Notes is not a structured, relational database

with a well-defined schema table. Notes databases were actually designed to be unstructured object

stores in which every document could potentially have a different set of data items from every other

document. In most real-world Notes applications there is, in fact, a fair bit of consistency, but a little

detective work is often needed to determine what the inner structure is. A good migration tool will help

you look at the forms, views, and actual data documents to develop a schema for extracting data out of a

Notes application.

Note that this job usually includes sorting out the data fields that were temporary fields used for the

application functionality, those that were simply never used in practice, and some that truly deserve to be

migrated. It may also include picking more user-friendly names than the internal names used in Notes.

Mapping the Notes schema to a SharePoint schema may be as simple as doing a one-to-one field

mapping; in more complex cases, you may need to significantly transform the data between the two

systems. A sophisticated migration tool will allow you to write formulas, perform lookups and apply other

data transformation techniques.

This is definitively a combination of both art and science. It helps a lot if you have access to someone

who understands what the application does and can help you figure out which information is actually

worth migrating and what it means.


Migrating Form Designs to InfoPath

When you provision a custom list in SharePoint, you get a default single-column form that SharePoint

generates for you. If this form is not good enough, you may need to build (or migrate) a custom form that

looks and acts like your old Notes form did. SharePoint gives you several ways to create great looking

custom forms:

Structure your solution as a SharePoint List and customize the default web pages used to add, view, and modify documents in SharePoint. This form of development usually occurs in SharePoint Designer and requires a good understanding of web parts, web parts pages, and SharePoint internals. This method probably gives you the most power and flexibility but it is an expensive prospect and may result in a solution that is relatively hard to maintain.

Structure your solution as a SharePoint library and use custom Microsoft Word templates to create complex documents. Your Word templates can contain content controls and be very structured and form-like. Word integrates with SharePoint very nicely, and portions of your Word documents can be synchronized with SharePoint properties for viewing and searching. This solution is usually only considered by organizations that have already standardized on Office template development as a strategy.

Structure your solution as an InfoPath form library (as described above) and design a custom InfoPath form template to edit and view them. This is a popular solution if you have complex, multi-level Notes documents. Many developers also consider InfoPath to be the ideal way to design custom forms that have a lot of advanced functionality. Again this is a somewhat expensive process and requires a good understanding of XML schemas and InfoPath tools. Also, InfoPath XML documents are rather heavyweight objects to process and the resulting solutions can seem relatively slow and clunky.

Structure your solution as a SharePoint lists, but use InfoPath forms to edit them. This is an exciting new capability that was introduced with SharePoint 2010. It is in many ways the best of both worlds: the data is stored as a simple flat SharePoint list and developers can use InfoPath Designer to create nice looking form layouts. The tight integration with SharePoint makes the experience seamless for both developers and end users, as shown in the figure below. This solution has already proven popular with organizations that have a large number of Notes applications of medium complexity, since it is far easier and less expensive than any of above solutions and the work can be performed by someone without deep SharePoint development skills.

Figure 13. Using InfoPath forms to edit SharePoint lists

Migration tools will give you the most assistance with the last two options. A high-end migration tool can

convert your Notes forms to InfoPath forms for use either in InfoPath form libraries or as InfoPath list

forms. (The two types of forms are actually quite different, so make sure that your tool can handle both.)

Typically a migration tool will do a great job with the form layout (fonts, colors, tables) and data entry

controls, but will not be able to migrate the formulas and events wired into your Notes forms. Certain

Notes development constructs such as sub-forms and tabbed tables simply don’t exist in InfoPath, so

some human intervention will probably be required. Your migration tool should give you a report of what it

could not migrate automatically, so your developers will now what they need to clean up.


The following figure shows a Notes form that was migrated to an InfoPath list form. Since this Notes form

did not have much functionality coded into it, the tool was able to do a pretty complete job with an

automated migration.

Figure 14. A Notes form that was migrated to an InfoPath list form using Notes Migrator for SharePoint

Migrating Approval Process and Workflow State

Organizations trying to migrate complex applications often consider workflow migration to be their biggest

hurdle. The basic problem is that in the Notes world, “workflow” consists of buttons, forms, agents and

scripts. In other words, all the workflow logic is buried in bits of code scattered throughout the application

and implemented differently by each developer.

This is quite different than SharePoint’s modern declarative workflow environment. With declarative

workflow you have a structured set of human-readable conditions and actions that is interpreted by a

central workflow engine. No migration tool is going to be able to automatically convert code-based

workflow to declarative workflow, so human intervention is definitely required here.

The good news is that implementing workflow logic is generally much easier in SharePoint than it ever

was in Notes. Don’t be dismayed when you find a Notes application with hundreds of lines of code;

depending on what that old code actually did, you may not have to write any new code at all.

First of all, much of the functionality that Notes developers had to write by hand is now available as an

out-of-the-box feature in SharePoint. This includes simple approval processes, version control, check-

in/check-out, subscriptions to content changes, and many other features you can now enable with a

single mouse click. In addition, a greater number of pre-built application templates are available, including

complete content publishing applications, meeting workspaces, issue and project tracking centers, and

other solutions that Notes people had to build from scratch. Finally, when you do need to write custom

workflow logic, you can achieve a good deal of it using the workflow authoring tools in SharePoint

Designer without writing code.

For all of these cases, you still have the issue with migrating the state of the workflow. The Notes

application probably contains data items that represent the approval status, the due date, people that

need to review the document, etc. A good migration tool should help you map the way your Notes

application expressed these concepts to the way SharePoint wants to express them.


Of course, plenty of existing Notes applications cannot be rebuilt using just code-free declarative workflow

“as is,” but many migration teams are looking at how they can simplify the application requirements so

they can. The result is an application that is easier to understand, maintain, and upgrade later.

Deploying Sandbox Solutions

Microsoft is very strict about what types of custom code you can deploy on their shared servers. In fact,

Microsoft will allow only custom code that is designed to run in a restricted “sandbox” environment. The

sandbox carefully controls what operations are allowed, ensures that programming errors cannot impact

other processes, and throttles the use of system resources to agreed-upon levels. As a result, customers

can upload their custom web parts and other SharePoint solutions and they will run just fine, provided

they have stayed within the limits of the sandbox.

Sandbox solutions can include not only web parts, but also custom site and list definitions, custom pages,

custom actions, custom workflows, content types, and event receivers. The real limitations come down to

what that code can do and the APIs that it can call. In general, it can read and write content at the site

level, but not at the web application, farm, or system level. The specific details are well documented by

Microsoft.

Another key aspect of sandbox solutions is how they are deployed. Since you don’t have access to

SharePoint Central Administration or STSADM utilities, everything is done through normal site

administration. Any site administrator can upload a sandbox solution into the Solution Gallery.

Figure 15. Uploading a sandbox solution to the Solution Gallery


Understanding the Limitations of Office 365 Since Office 365 is a hosted application environment running on shared server farms, it does have some

limitations compared to an on-premises SharePoint 2010 environment. These limitations generally make

sense when you consider that Microsoft is obligated to achieve a 99.9% uptime as well as make

absolutely sure that there are no security leaks between various customers on the shared servers.

Understanding these limitations will help you quickly determine what applications will not be good

candidates for migration to Office 365, or what compromises you may have to make to host them there.

Connecting to Enterprise Data

Perhaps the most frustrating limitation for Notes customers is the lack of a way to connect the hosted

SharePoint servers to all the existing applications and databases inside the organization. After all, some

Notes applications were built for the express purpose of front-ending other systems (whether to bring data

together in a new, friendlier user interface or to supplement it with additional collaboration or workflow

capabilities). SharePoint 2010 has a number of exciting features that help achieve similar goals, but

unfortunately these are disabled in Office 365 until further notice.

One partial workaround to this problem is to design applications that bring enterprise data together in the

user’s web browser rather than on the server. For example, you can build a web page that loads from

SharePoint and reaches out to your Enterprise systems directly from the browser. This can be pretty

advanced development work so many organizations may elect to simply deploy an internal SharePoint

site if they have an urgent need for this type of application.

Mail-In Databases

Mail-in databases have been a fundamental Notes construct since the early days of Notes and some

organizations depend heavily on them. The idea is that one can set up a mail alias that is associated with

a particular database. When a user sends an email to that alias, the message is deposited into that

database. Developers can program a variety of event handlers to process the incoming documents,

initiate workflows, etc.

SharePoint has a similar capability that works quite well, but for some reason this has been disabled in

Office 365. This means that you cannot send mail to a list or library in SharePoint Online, which

effectively reduces the number of applications that can be deployed there.

The workaround to this problem is to set up an Exchange Online mailbox and write an eternal utility that

routinely polls the Exchange mailbox and copies any new documents to SharePoint. It is not very difficult

to develop such a utility, but it may be cumbersome to deploy and manage, and it adds another potential

failure point to your application environment.


Deploying Custom Code

As discussed earlier, Microsoft will only allow you to deploy custom code to their servers if it runs as a

sandbox solution; this significantly limits what the code can do.

The good news is that the latest version of SharePoint allows for a great deal of customization and light

development, without having to resort to writing code. A detailed survey of SharePoint Online

development options is beyond the scope of this paper, but it is our belief that teams who are migrating

Notes applications can now do almost everything they need to do via browser-based customization, using

tools such as InfoPath and SharePoint Designer, and by writing the occasional sandbox solution.

To a hardcore SharePoint developer who likes to build advanced solutions in Visual Studio, these

restrictions can seem very limiting. Indeed, there will be some solutions that end up being too complex to

run on SharePoint Online. But these will be the exceptions.

Standard Server Settings

Most of the settings in SharePoint Central Administration are not available in Office 365 (see Appendix A

for details). While this makes the job of managing your sites much simpler, it will no doubt be a source of

irritation to many customers from time to time.

The bottom line is that Microsoft decides your default farm and web application settings and there is not

much you can do to change it. For example, SharePoint maintains a list of file extensions that are not

allowed in sites (mostly for security reasons). Farm administrators often modify this setting because they

decide that in their environment it is important to allow users to upload, say, .EXE files. In SharePoint

Online, you have a fixed list of blocked file extensions and a size limit of 250 MB per file. You will never

have the option of changing that setting.

Microsoft has also set limits for site collection size (100 GB), number of site collections per tenant (300 for

Enterprise customers), and total tenant storage (5 TB). These limits may change over time.

Bandwidth and Throttling

Your performance may sometimes be limited by the bandwidth and latency of connecting to your sites

hosted by Microsoft. If your organization has a great internet connection, this may not be much different in

practice that than connecting to an on-premises environment, and for remote users it may even be a lot

better.

Resource throttling may also limit performance. Specifically, SharePoint may throttle resource-intensive

site collections so they do not cause other sites in the shared environment to degrade (for more details,

see Appendix A).

For normal usage, neither of these factors may be that material. Most SharePoint applications are not

very bandwidth intensive. Also, any performance limitations imposed by the shared environment are

usually made up for by the scalability the Microsoft achieves by deploying more servers than most

organizations would choose to invest in.

Where you may notice a difference is in the migration process itself. Your migration tools are uploading

and writing documents as fast as they can, and that can represent a very atypical load on both bandwidth

and performance.


Other “Missing” Features

Several other SharePoint Enterprise-level features are not included with Office 365. These features do

not really impact Notes migrations per se, but they are worth knowing about when planning your migration

project:

Records Center

FAST search and related features

Web analytics


Conclusion Transitioning to a new platform, such as Office 365, requires planning and analysis, good migration

tools and procedures, and good management of user expectations. Understanding the issues and

recommendation discussed in this white paper will help your organization migrate your Lotus Notes

and Domino applications to SharePoint Online quickly and effectively.


Appendix A - SharePoint Online Deployment Basics Getting Started

The first step in deploying SharePoint Online is to get an Office 365 account. As of this writing, Office 365

is still in beta, so you need to request a beta account from Microsoft. After the beta period is over, you

can sign up for an Office 365 account using your credit card (a free trial period may also be available).

Either way you can start from this URL: http://www.microsoft.com/office365. Many consultants and other

partners will be in the business of helping organizations get up and running with Office 365 and

SharePoint Online.

Office 365 includes a lot more than just SharePoint, of course. Many aspects of using Office 365

are beyond the scope of this paper, including Exchange Online email accounts, Lync Online instant

messaging and conferencing functionality, and the option to install Word, Excel and other Microsoft

Office applications on each user’s desktop. Lotus Notes customers in particular may well want to

migrate their users’ mail and calendar databases to Exchange Online before or in parallel with their

application migrations to Exchange. (The good part is that you can proceed in whatever order makes

sense for your business.)2

When you place your initial order, you will be asked to establish an initial administrator account for

managing the environment and adding other users. This account will be a Microsoft Online Services ID, a

login account managed by Microsoft. If you are familiar with Windows Live ID (formerly known as

Microsoft Passport), this will seem familiar to you, since the directory systems are very similar.

Figure 16. Establishing an administrator account for Office 365

2 For more information on migrating to Exchange Online, see Key Considerations When Migrating Notes & GroupWise

Email to Microsoft Office 365.

http://www.microsoft.com/office365

http://www.quest.com/documents/landing.aspx?id=14196&technology=&prod=&prodfamily=&loc=

http://www.quest.com/documents/landing.aspx?id=14196&technology=&prod=&prodfamily=&loc=


You will also be asked to specify the level of service you want to start with. Be sure to select a package

that includes SharePoint!

Choosing the Right Office 365 Plan

You can choose from among several levels of SharePoint Online. Enterprise customers (really anyone

with more than 25 users) can choose between SharePoint Kiosk, SharePoint Plan 1 and SharePoint Plan

2. Refer to the Microsoft web site for up-to-date information about exactly what is included in each level,

but here is the upshot for Notes migration customers: All levels include all basic SharePoint functionality,

so any one of them will meet the needs of migrating the bulk of your Notes applications. The biggest

difference will appear when you start migrating custom/complex Notes applications. SharePoint Plan 2

includes the use of InfoPath form services and InfoPath list forms. As we saw earlier, these technologies

can be a huge cost saver if you have a lot of custom Notes forms to migrate. (Organizations that are

planning to build a lot of custom SharePoint applications may also benefit from Access Services, Excel

Services and Visio Services, which also are all part of SharePoint Plan 2.)

What will be confusing to some people is that these SharePoint plans are bundled inside a variety of

broader Office 365 plans. For example, SharePoint Plan 2 is part of the Office 365 E3 and E4 plans,

which also include the more expensive Exchange and Office ProPlus components. The good news here

is that you don’t have to stick with the advertised bundles. You can buy SharePoint Online by itself or add

a higher level SharePoint plan with a lower level bundle.

Even better, you can choose your plan on a user-by-user basis. You can buy kiosk plans for the majority

of your users and buy a more expensive plan for the users who need advanced forms, etc.


Basic Tenant Administration

Your Office 365 account will often be referred to as a “tenant” in the Office 365 literature. This is because

your SharePoint sites, etc., are really part of a much larger, shared (i.e., “multi-tenant”) server farm hosted

by Microsoft. The Tenant Administration tools that Microsoft provides allow you to safely and securely

manage your little slice of that shared environment without impacting any of the other tenants.

Once you have established your basic Office 365 plan and administrator account, you log into

https://portal.microsoftonline.com/ to manage your account:

Figure 17. Managing your account

The basic getting-started information on the site will guide you through the process of setting up a

publically available domain name for your site (you can use your own, if you already have one) and

adding additional user accounts (discussed below). New users that you add will automatically get

Exchange mailboxes and access to the other Office applications unless you specify otherwise.

The link for managing your SharePoint Online sites is highlighted in the figure above. This link will take

you to the SharePoint Online Administration Center where you can create new sites, enable InfoPath

form services, manage user profiles and “My” sites, and manage the central term store.

Experienced SharePoint administrators can think of this area as a very simplified version of SharePoint

Central Administration. You don’t have to deal with configuring web applications, content databases,

service accounts, backups, or anything to do with SharePoint farms. All of that is managed by Microsoft

for you. This new administrative interface makes it possible for administrators or partners to manage the

basics with little or no training.

Before digging into SharePoint site administration, however, it is important to learn how end-user

accounts get created in Office 365.

https://portal.microsoftonline.com/


Adding Users and Synchronizing Directories

Office 365 provides several ways to configure users. The simplest way is to use the Add User wizard. You

can specify the logon information, the access rights or administrative rights you want to grant to the user

and the type of license you want to allocate for that user.

Figure 18. Adding users with the Add User wizard

At the end of the process, the user receives an email with a temporary password that allows her to

establish a Microsoft Online Services ID for accessing Office 365.

If you have more than a few users, adding them one at a time using the wizard can get very tedious, very

quickly. Therefore, Office 365 includes a bulk import tool for adding multiple users via a CSV file.

Whether you use the wizard or bulk import tool, the logins you establish are completely disconnected

from the accounts you maintain in your internal directory system. Fortunately, Office 365 enables you to

set up automatic directory synchronization. This involves downloading a Directory Synchronization tool

which you deploy on an internal server. This tool keeps the Active Directory accounts in your internal

environment synchronized with your Office 365 environment.

You can even take this one step further and establish single sign-on, allowing users to use their existing

Active Directory corporate credentials to access their hosted applications. That is, instead of logging into

Office 365 via a separate Microsoft Online Services ID, users will actually authenticate using your internal

server. This requires you to deploy Active Directory Federation Services (ADFS) 2.0 internally and

exchange federation credentials. Setting up Directory Synchronization and single sign-on are both

beyond the scope of this paper. The important take-away here is that both are possible and you can

count on being able to use all your corporate user and group accounts in your SharePoint sites.


Two other user accounts are worth mentioning:

External contacts – You can add external contacts in Exchange; these are users that you can send email to but that are not counted as real licensed users.

Extranet users – You can invite a limited number of extranet users outside your company to access and participate in certain SharePoint sites using partner access licenses. These users are sent invitations via the Share Site action in the SharePoint site and also do not count as full licensed users.

Provisioning and Managing Site Collections

As shown below, the SharePoint Online Administration Center allows you to manage your site collections.

To create a new site collection, go to the Site Collections area and click the New button. Depending on

the type of Office 365 account you have, you make have the choice of creating an internal site collection

or a public-facing web site. The latter would be appropriate only for small businesses; Microsoft does not

(yet) expect large organizations to host public web sites on Office 365.

Figure 19. Managing site collections with the SharePoint Online Administration Center

The parameters for creating a new site collection are straightforward. You can specify the title, the URL,

the site template, the time zone, and site administrator. Note that the list of available templates is slightly

different than what you would expect to see in an on-premises SharePoint environment. Certain

templates, such as Record Center, are not available on Office 365, but some new templates, such as

Express Team Site, have been created just for Office 365 customers.

You can specify two interesting quotas about each site collection:

Storage quota – Limits the size of the site collection.

Resource usage quota – Limits how much processing power the site can consume. This was introduced with SharePoint 2010 and allows administrators to throttle one site collection so that it does not slow down all the other sites in your shared SharePoint farm. That is, you will be allocated a certain amount of space and processing resources with your Office 365 account and you can decide how to allocate those resources between your site collections. If you need to go beyond the limits allocated to you, you will be able to purchase additional resources for a higher monthly charge.


You can also view and change the properties for existing sites using the SharePoint Online Administration

Center. Simply select any of your sites and use the toolbar at the top of the page. Four are of particular

importance:

Owners button – Lets you add additional site collection administrators (you can specify only one when you first create the site collection).

Quota buttons – Allow you to set up alerts for site collections near their Storage or Resource Usage limits.

Manage Share By Email button – Allows you enable the automatic invitation of extranet users via email.

Settings button – Allows you to designate one of your site collections as the default site collection. This is important because it determines what site users will link to from their Office 365 home pages.

Building your SharePoint Sites

Once you have created your SharePoint Online site collection, you can configure and use it just like you

would an on-premises SharePoint site. There are only a few limitations, as discussed earlier in this paper,

and you will be amazed at how much functionality is now available to you. If you are new to SharePoint

2010, you will probably spend more time learning about what’s new in SharePoint 2010 than you will

worrying about the nuances of SharePoint Online.


About the Author Steve Walch is a senior product manager at Quest Software. He has been a Lotus Notes and

Microsoft technologist since 1993. In 2002, he founded Proposion Software with the mission to

connect Lotus Notes with the emerging Microsoft .NET development platform. Over time, Proposion

focused on Notes-to-SharePoint migration and integration tools, and became the leading vendor in

that market. In 2007, Proposion was acquired by Quest Software. Walch developed Quest Notes

Migrator for SharePoint, which has been used by organizations of all sizes around the world to execute

successful migrations. His Notes 2 SharePoint blog (Notes2sharepoint.org) is highly regarded

by industry experts and analysts.

http://www.notes2sharepoint.org/

5 Polaris Way, Aliso Viejo, CA 92656 | PHONE 800.306.9329 | WEB www.quest.com | EMAIL [email protected]

If you are located outside North America, you can � nd local o� ce information on our Web site.

WHITE PAPER

About Quest Software, Inc.

Quest Software (Nasdaq: QSFT) simplifies and reduces the cost of managing IT for more

than 100,000 customers worldwide. Our innovative solutions make solving the toughest IT

management problems easier, enabling customers to save time and money across physical,

virtual and cloud environments. For more information about Quest solutions for application

management, database management, Windows management, virtualization management

and IT management, go to www.quest.com.

Contacting Quest Software

PHONE 800.306.9329 (United States and Canada)

If you are located outside North America, you can find your

local office information on our Web site.

EMAIL [email protected]

MAIL Quest Software, Inc.

World Headquarters

5 Polaris Way

Aliso Viejo, CA 92656

USA

Contacting Quest Support

Quest Support is available to customers who have a trial version of a Quest product or who

have purchased a commercial version and have a valid maintenance contract.

Quest Support provides around-the-clock coverage with SupportLink, our Web self-service.

Visit SupportLink at https://support.quest.com.

SupportLink gives users of Quest Software products the ability to:

• Search Quest’s online Knowledgebase

• Download the latest releases, documentation and patches for Quest products

• Log support cases

• Manage existing support cases

View the Global Support Guide for a detailed explanation of support programs, online services,

contact information and policies and procedures.

© 2011 Quest Software, Inc.ALL RIGHTS RESERVED.

Quest, Quest Software, the Quest Software logo are registered trademarks of Quest Software, Inc. in the U.S.A. and/or other countries. All other trademarks and registered trademarks are property of their respective owners. WPW_MigrateLNApp_MOffice365_SPOnline_US_EC_20110615