Five ways to prepare for SharePoint 2013 Written By Chris McNulty, SharePoint Strategic Product Manager

Abstract

Introduction

Many organizations are eagerly anticipating the next version of SharePoint, SharePoint 2013, which is expected in early 2013. But there’s more to do than just sit and wait: you can take concrete steps today to prepare your environment for the new release. Taking those steps will gain you immediate benefits in your current environment and ensure you are ready to quickly take advantage of new SharePoint 2013 features.

SharePoint is a powerful and rapidly expanding platform for enterprise collaboration. Two years after the release of SharePoint 2010, Microsoft is gradually revealing details on what users can expect in SharePoint 2013, which many anticipate will be available in early 2013; expectations are beginning to surface around social capabilities, the cloud and a new interface. Organizations of all shapes and sizes from all parts of the globe are considering how they will migrate, consolidate and restructure their legacy SharePoint sites, Windows file shares, Exchange public folders and Lotus Notes applications to the next SharePoint version.

In this white paper, SharePoint expert Chris McNulty offers a SharePoint 2013 readiness plan that details five specific actions organizations should take to prepare their environment for the future.

Why Begin to Prepare Now? A migration to SharePoint 2013, like any other SharePoint migration, is not just about moving data from point A to point B. Migrations are long, complex, risky and expensive projects, and it is critical that organizations prepare their current environment properly to ensure that they’re set for a successful migration – now and in the future.

Everything you do in your environment should be implemented with an eye on how it will impact the inevitable evolution of your SharePoint platform.

Share:

2

The reality of a Microsoft world is that new versions come every three to four years. Everything you do in your environment should be implemented with an eye on how it will impact the inevitable evolution of your SharePoint platform. Migrations are – or at least can be – designed to achieve a business outcome, whether it’s streamlining information architecture or gaining operational efficiencies. So when your organization considers a migration, you must plan effectively to ensure that the project will achieve your intended results. Failing to implement the proper governance around migration readiness can lead to a number of risks and challenges, including the following: • Ensuring that migrated content will be useful and searchable in the new environment can be difficult. • Migrating legacy applications and other custom code is costly and time consuming, with high risk of downtime or data loss. • Ensuring that only relevant content is migrated to the new environment is a challenge unless the organization fully understands what’s in the current environment. • Migrating large amounts of data is time consuming and can result in over-sized databases that will slow • SharePoint performance in the new environment. • Managing the migration of disparate SharePoint versions and collaboration systems can be chaotic, placing heavy burden on the IT staff.

Overview of the steps to take now As organizations begin to consider SharePoint 2013, there are many ways they can prepare their environment today to gain immediate benefits now, and also be ready to quickly take advantage of new features later. It is essential that organizations put a “SharePoint 2013 readiness” plan into action. This white paper details five specific actions organizations should take to prepare their environment for the future: 1. Develop a governance plan – Establish a governance strategy in your current environment to plan effectively for the future, leveraging lessons learned to identify required infrastructure or architecture changes. This will enable you to design and implement a mature, go-forward governance plan before your migration to mitigaterisk and ensure data security, usability and searchability from day one in the new environment. 2. Choose code-free customization – Migrating custom code is costly and time consuming and introduces a high risk of downtime or data loss. Implementing a code-free development methodology now – utilizing tools and techniques that you know will be upgradeable and supported going forward – will reduce the burden and risk of migrating custom applications. 3. Perform inventory and analysis – Discover and inventory existing content to determine what should bemoved and in what order, and what can be purged, archived or consolidated before migration. A well-defined retention policy is a governance best practice and ensures that only relevant content makes the move to

the new environment, reducing project time, cost and complexity. 4. Consider data externalization – Before your migration, get your systems in place to move large, old and unused data from SQL Server content databases to secondary, less expensive repositories. This will deliversystem efficiencies in the short term, slash migration timelines and ensure high performance in the new SharePoint environment. 5. Perform content consolidation – Eliminate the islands of SharePoint and other legacy collaborationplatforms in your environment, such as Windows file shares, Exchange public folders and Notes applications, by centralizing the content and, if applicable, migrating content to SharePoint 2010. Doing so will ensure a much smoother upgrade to SharePoint 2013 – and a more useful and usable new environment.

Step 1: Develop a governance plan What is Governance? Establishing clear and effective SharePoint governance is the first step in preparing for SharePoint 2013. But exactly what is SharePoint governance? Microsoft provides a succinct definition on TechNet: “Governance is the set of policies, roles, responsibilities, and processes that guide, direct, and control how an organization’s business divisions and IT teams cooperate to achieve business goals.”2 (emphasis added) What does this mean in practical terms? How do you go about defining these policies, roles, responsibilities and processes, and in implementing and sustaining a governance program? Begin with Business Outcomes Crafting any kind of governance plan begins by talking about business outcomes. Simply getting everything running on the new version of SharePoint is not a business outcome. Of course, when you move to the latest

version of Microsoft’s platform, you’re ensuring mainstream support for years into the future, along with the usual stability and performance enhancements you get with each new version of the product. But that’s not the main reason to consider an upgrade or migration. Your adoption of SharePoint 2013, whether you’re upgrading from an older version or migrating to SharePoint for the first time, should be driven by taking advantage of capabilities of the new platform. Consider where you want to be a year or 18 months after the migration. Envisioning what the end game looks like will enable you to better understand your current environment and the steps you need to take to get where you want to be. For example, one of your goals might be to improve employee retention and accelerate the discovery of relevant information by using enterprise social channels to deliver information to people at point-of-need. Microsoft has already disclosed its broad commitment to social technology in SharePoint (although the details haven’t yet been publicly unveiled), and even SharePoint 2010 provides greatly improved social capabilities compared to older versions of My Sites. Consider what you want to do with an expanded set of features in this area. Perhaps your vision for the future is to be using SharePoint universally across cloud-distributed users, so that regardless of where people are in the world and regardless of whether they’re in the company or outside the company, they are able to contribute to document-based collaboration in certain ways, participate in particular kinds of business processes, and help the organization make more accurate and timely decisions.

2 http://technet.microsoft.com/en-us/library/cc263356.aspx. For additional SharePoint governance material, see http://technet.microsoft.com/en-us/sharepoint/ff800826.aspx

Share:

3

Envisioning what the end game looks like will enable you to better understand your current environment and the steps you need to take to get where you want to be.

It’s important to ensure that governance gives voice to business goals, operations teams, technology management and users.

Consider current policies As you establish your preferred business outcomes, think about whether and how your current policies and procedures support those goals, for both SharePoint and non-SharePoint material. For example, you may have information residing in file shares. I don’t often recommend that people go out and carve out governance plans for file servers, but if you look carefully, you may discover that you have elements of your SharePoint governance in the policies that govern non-SharePoint materials. There may be retention policies that specify how long to keep particular kinds of content in a file share, or guidance that’s given to new employees that specifies what types of things they are allowed to put on the network – for example, perhaps PowerPoint presentations are fine but MP3 files are prohibited.

Understand the development and revision cycle for governance It’s important to see governance as a cycle of continuous improvement, rather than a single implementation. No effective SharePoint governance program can be implemented in a onetime, one-day burst of activity. Instead, governance typically cycles through multiple core processes. Although each of these activities warrants its own white paper, here is an overview of the cycle for development and refinement of SharePoint governance: Establish stakeholders Although SharePoint often begins as an IT initiative, SharePoint is really business software for business users. Just as successful SharePoint implementation projects need to engage a cross section of business owners, it’s important to ensure that governance gives voice

Establsh stakeholders

Evaluate success for next steps

Gather requirements

Measure results

Develop governance framework Implement governed operations

Figure 1. SharePoint governance cycle

Share:

4

to business goals, operations teams, technology management and users. Stakeholders may be fluid through the years, but stakeholder engagement should remain constant beyond the original implementation project. Keeping business sponsors engaged can be a challenge for some organizations without a tradition of business steering and governance. It helps to ensure that governance reviews, meetings and communications are focused and efficient to sustain engagement. Gather requirements Governance begins with an understanding of business goals. Over time, it also transits to include tactical needs and system capabilities and constraints. Shepherding this process is complicated. Working with business and technical disciplines requires education, tact and careful translation to assure that all governance decisions are made in consideration of commonly understood goals. Develop governance framework Policies and procedures are the key outputs of this activity. Turning governance requirements into effective, enforce-able policies and procedures is a complex process. The governance pyramid discussed above can help you prioritize the areas and sections of your farm that require the most attention. Policies and procedures should be documented as much as possible. implement governed operations This is another huge endeavor. Training and communications are parts of this process. Procedures should be automated to the extent practical. Matching the tactical execution to the governance strategy requires perception and cultural awareness. Practical governance works across multiple user scales – from individuals through an entire user ecosystem. It also may vary from broad usage guidelines to tightly controlled and restricted policies. Parts of implementation may involve additional software tools or custom

Share:

5

development. It may also lead to new technical training and operating practices. Measure results Sustained governance programs require some degree of evaluation. In 200/300-level governance, much of this evaluation is based on qualitative or narrative feedback. But as higher levels of maturity are reached, statistical evidence can be gathered, such as monthly site requests compared to actual site creations. Evaluate success for next steps All governance programs require ongoing evaluation to determine if they are effective in channeling SharePoint to help achieve business goals. Again, it’s not going to be perfect at first, but if stakeholders are able to make honest appraisals of their success, they can determine next steps. One of those next steps may be identifying additional stakeholders. In that case, continue back to the top of this list!

Step 2: Choose code-free customization Why avoid complex customization? An important step in migration readiness is to assess what custom code you have in your environment, and to take steps to reduce or eliminate custom code now and in the future. Why? In general, if you stay “in the box” with SharePoint, migrations and upgrades tend to run pretty seamlessly. But the more customizations you’ve done – whether they’re changes to the UI, rewriting of style sheets, or more intrinsic changes that go down to the fundamen-tal layers of SharePoint – the more testing you have to do, the more variability you get, and the greater the possibility there is of running into things that can delay or even prevent a smooth upgrade or migration. Therefore, organizations need to understand how much custom code they have in order to accurately estimate the difficulty and risks of an upgrade or migration. Sometimes, custom code

Organizations need to understand how much custom code they have in order to accurately estimate the difficulty and risks of an upgrade or migration… because if it’s too hard to rewrite the custom code, the entire upgrade or migration project may get shelved.

can even become an overweight anchor that ties you down to a legacy platform – because if it’s too hard to rewrite the custom code, the entire upgrade or migration project may get shelved.

Empowering your citizen developers is a good practice – and so is educating them about the best and most supportable and upgradeable ways to enhance SharePoint.

How much custom code do you have, and how is it used? Evaluate your customizations now, before the migration. Some people may have used the SharePoint platform to write workflows in SharePoint Designer or other tools like Nintex or K2. You may discover that people have written clientside code using techniques like jScript or jQuery. They also may have compiled new coded solutions for custom applications or branding. But don’t look just at how much custom code you have; look at how much it is used. You might find that custom code is used lightly or not at all, and just like obsolete content, it may be purged. The concept of application lifecycle management is not unique to SharePoint or Microsoft. Applications often age like stars: • Beginning – Application usage explodes in a rush like a supernova. • Middle – The application sees mature, consistent usage, like the current glow of our sun. • End – Application use dwindles down and goes cold, like a black hole of all mass and no light.

Retire or Replace Existing Custom Code Get those black hole applications out of there! For instance, one organization had a great custom interface for requesting and mailing CD copies of internally produced audio files. But they found that the interface was no longer being used, and therefore they were able to retire it as part of their (early) migration preparation. Of course, you may find that some custom applications are still needed. For the functionality you do need to keep, it may be easier to simply replace the custom code now with a more component-based, supportable process, using tools and techniques that you

Share:

6

know will be upgradeable going forward. You will likely discover most custom code is poorly documented, so this process can take some work, but it is better to tackle it now than during or after your upgrade or migration. Why? When you change platforms, you have to ensure that your custom applications work on the new platform. Upgrading from SharePoint 2007 to SharePoint 2010, for instance, is fraught with gotcha’s because of platform differences. The first challenge is simply getting the application to run on the new platform. A lot of independent software development at the grassroots level can be quick and dirty. For instance, the code may include hard-coded references to databases, server names or URLs – which worked just fine until you try to run the code on a new platform. So, simply getting custom code to run on the new platform can be difficult, or even impossible, especially for a lean IT shop. Equally challenging is making sure the application works correctly on the platform. The code was developed to serve a business use, and there is the very real risk that what was done before isn’t perfectly repeatable. If it’s not repeat-able, then you lose the ability to do whatever the code was built to do in the first place. But there’s an even more insidious risk than losing your custom solution altogether: the risk that the solution comes back different. If the custom solution works but is somehow wrong, you introduce error into a process that was error-free before. Switching from custom code to prebuilt components now will shift the compatibility burden from you to the software publisher, both for your move to SharePoint 2013 and for migrations further down the road. Establish policy for avoiding further custom code You should also establish and enforce a policy to avoid using custom code for any changes you’re currently contem-plating

or that you will want in the future. Instead, choose tools and techniques that you know will be upgradeable going forward. You can customize your SharePoint the way you want without custom code and the problems it engenders. Note that none of this advice is meant to discourage “citizen developers” – information workers with personal understanding of their technical needs who create their own business applications. You simply need to enable and accustom them to do so without writing code. Citizen developers can use tools like InfoPath, SharePoint Designer workflows, and web part-based components. Empowering your citizen developers is a good practice – and so is educating them about the best and most supportable and upgradeable ways to enhance SharePoint. Microsoft has always offered lots of ways to do the same thing. Steering citizen developers to the “best” mix of techniques – governance – enhances the long-term value of their solutions. In fact, SharePoint delivers maximum value when we understand that it’s a business-facing platform, not just technology for technology sake. Empowering citizen development eliminates the back and forth of “I think this is what you said you needed – is this really what you said you needed?” Citizen development takes advantage of the fact that the people who intend to use the process usually are the best experts on what the process needs to be. For example, a given set of workflow approvals may need to run four days a week and not five; for some reason, that group just doesn’t do them on Mondays. A developer who sits down to create the workflow may not think to ask what days of the week to include, but the people who own that process understand implicitly all the rules of engagement. The more they are empowered to build their own solution (or to at least frame it out to a point where someone else can finish it), the stronger the result will be. But using the right solutions, like

Share:

7

supported web parts, rather than custom code, will yield a solution that is easier to implement, easier to support and easier to migrate.

Step 3: Perform inventory and analysis Why inventory and analyze your current environment? To effectively plan your upgrade or migration, you need to assess your current environment, including nonSharePoint resources. The governance you developed in Step 1 should help tell you what you need to inventory – and what you don’t. For example, you may have a policy that employees not put personal files on network shares. But when you look, you may find that the truth of the matter is that they’ve been doing that for years without being noticed, and those files may cause all kinds of issues in your migration. Similarly, you may have the best of intentions about your retention policy, but never actually turned it on, or you may have turned it on but never actually measured it. Now is a great opportunity to look at content and soberly evaluate what should be kept and what should not. For instance, you might find 10-year-old files from a division that no longer exists, or files that have all been backed up to tape anyway. Do you need to retain them? Many times the answer is no. Of course, it is not up to IT to determine that something is irrelevant; that’s a business decision. IT needs to work hand-in-hand with the business owners because only the business can say, “Of the 45,000 public folders that are out there from Exchange, I care about only 3,000 of them. The rest can all be dumped, since they’re already on tape and no one looks at them anymore.” Practicing how to approach these kinds of decisions and their execution when it comes to file shares will enable you to make similar kinds of decisions better and faster in the SharePoint setting. For

Now is a great opportunity to look at content and soberly evaluate what should be kept and what should not. Of course, it is not up to IT to determine that something is irrelevant; that’s a business decision.

Make sure you have the proper patch levels before you begin your migration.

example, your organization’s vision might be that SharePoint should be an application platform, but you may discover that SharePoint is not actually being used that way. For example, you might find that core business processes are being driven solely by email; that is, even though you could be using SharePoint for an approval workflow, you’re using email to approve things. Analyzing your current processes will help you refine your governance plan and enable you to take steps now to address gaps in its implementation. Engage business owners in a dialog It’s important to understand that the inventory and analysis process is a dialog. You can’t simply sit down with your business counterparts and say, “Tell me what I don’t need to migrate” because they don’t necessarily know what’s out there any more than you do. Instead, some high-level categorization and inventory probably needs to be done before you can reasonably ask what should and should not be migrated. Of course, some business owners are fantastic; they’ll say something like, “We have the same content both on our web site and on the L-drive, and I don’t want people to have to remember to look in two different places. In the migration, I want the L-drive to come over as its own document library and call it “archive,” and to set up a new environment for everything from SharePoint and that will be where all the prime content lives. Then when each future project ends, I want its content to move from the primary area to the archive area.” But you can’t expect all business owners to lay out such complete and sound business rules without the dialog. Assess readiness You should also assess your readiness in three areas, technical, operational and business.

Share:

8

Technical Readiness Technical readiness involves understanding your current environment, both physically and logically. Physically, what servers do you have, what version of SQL, what versions of OS, what patch levels? How many farms do you have and how large are they? Do you have multiple regions, such as dev, test and production? How is everything built out at a physical level? Why is this important? Consider patch levels. In the assessment process, you may discover that your versions of SharePoint are running un-patched, and you need to make sure you have the proper patch levels before you begin your migration. The SharePoint 2007 to 2010 upgrade required at least a Service Pack 2 to do some of the upgrade readiness, and a subsequent cumulative update was needed to kind of get full upgrade readiness assessment. We anticipate similar requirements for the upgrade to SharePoint 2013. Microsoft has not made those patch levels public yet, but at a minimum, your 2010 environment should be on SP1, and you should watch for subsequent patches. Microsoft issues cumulative updates in even-numbered months; the last one at press time was April 2012. In addition to the physical level, you should understand your environment on the logical level. How are your sites organized – by geography, by division, by project, by people, or something else? How is information being classified? Does everything just go in as a document or are there content types that provide some rough level of segregation? For instance, there may have been any attempts to use SharePoint 2010 to manage metadata (or use of site columns in older SharePoint versions) to standardize document classifications. Building a well-defined taxonomy—a managed syntax for describing information hierarchically—can be immensely helpful. For example, consider how we classify living

things into an animal kingdom and a plant kingdom, and from there into vertebrates and invertebrates, and so on. If you’re running a zoo and a new animal shows up, that taxonomy will help you determine which cage it should go in; if it’s a vertebrate > mammal > primate > chimpanzee, then it belongs in the chimp area. I’m not saying your SharePoint environment is a zoo (I hope it isn’t!), but having a taxonomy for your electronic resources will make it easier to operate your whole organization. It will also make it easier for people to find the information they need with precision.

Assess usage patterns Finally, an inventory of your current SharePoint usage patterns is helpful throughout the upgrade readiness cycle. It’s essential to a governance program – what exactly are we governing? It’s also vital for establishing or enhancing enterprise content management (ECM). SharePoint 2010 itself already offers content lifecycle tools. Identifying the scope of aged or obsolete content allows you to set up the right ECM lifecycle policies and workflows to help reduce the glut of stale data with archiving or deletion.

Operational readiness (maturity model) Take a look at how far you’ve come with your previous SharePoint implementation. Are you sophisticated with business intelligence? With infrastructure management? Have you done the right things with search? Take the time to fully understand what is actually happening in your SharePoint today. Be sure to get the full, unvarnished truth, so you can understand how much further you have to go to get to the outcomes you want. Fully mature SharePoint environments aren’t built in a day, and you will never get there unless you can assess operationally how you’re approaching SharePoint.

Use the results The results of your assessment will help you refine your governance plan, help you decide what changes to make now, and inform your migration strategy. It’s important to understand what not to build into the migration plan. For example, if you want to automate your HR hiring process, you don’t need to introduce that specifically as part of upgrade readiness, but it is a good business strategy to map the upgrade to be able to support the automated process.

Business readiness What are your business goals for SharePoint? What are the outcomes that it is currently supposed to be hitting? Can we measure them? Are we achieving them or not? If you are, that’s great; make sure you know how to sustain that success after the migration. If not, analyze what’s missing and how best to proceed. Remember the six stages of SharePoint governance programs, and recognize that you should try out solutions, re-assess your success, and possibly try a different solution that might work better.

Share:

9

Consider an analogy. In any car race, such as Formula One, NASCAR or Indy, no matter how fast the cars go, they do stop for a few seconds to change the tires. You simply can’t change the tires of a moving car. Similarly, you can’t perform too much re-engineering work during your migration; instead, you just need to map out the plan for it and make sure you’re laying down the right foundation for your business outcomes.

Step 4: Consider data externalization Benefits of data externalization Your inventory and analysis process likely revealed some (or maybe many) large, old and unused data. Your governance may determine that some of this data can be purged – but that some of it needs to be kept for opera-tional or regulatory reasons. Consider moving this little-used but still-needed data from SQL Server content databases to

An inventory of your current SharePoint usage patterns is essential to a governance program, and is vital for establishing or enhancing enterprise content management.

secondary, less expensive repositories before your migration. This will deliver system efficiencies in the short term, slash migration timelines and ensure high performance in the new SharePoint environment. In fact, Dell’s testing has shown up to a 40 percent average SharePoint performance gain due to data externalization, based on real-world conditions both during regular use and during migration.

Our testing has shown up to a 40 percent average SharePoint performance gain due to data externalization, based on real-world conditions during regular use and during migration.

How does data externalization deliver these performance gains? When you offload old and unused data, your databases become smaller and more of them fit in memory, which reduces the processing overhead that goes on every time anyone writes to or reads from those databases. Plus, the smaller databases are faster and easier to back up and restore. And the size of a content database is directly proportional to the time needed to rebuild its internal schema during patches and upgrades. Both small and large sharepoint installations benefit from data externalization People often think that data externalization delivers performance benefits only for the largest SharePoint implementa-tions. Not true. You don’t need to wait until your content databases exceed 100 GB to see performance gains. In fact, data externalization can boost performance significantly even when the databases are smaller. Why? Because if every time anyone pushes content in or out of a database, they generate one or two SQL transactions instead of eight, the system will run a lot faster. Externalizing old and unused data now also means you have less data inside SharePoint to migrate, which speeds the migration process and reduces risk. Plus, learning data externalization technologies now will mean one less set of skills to master in the next environment. What you learn today will be transferable forward into SharePoint 2013.

Share:

10

Step 5: Perform content consolidation Why consolidate content? As we saw in Step 1, migration should not be simply about getting to the newest release; migration offers opportuni-ties to improve your environment. As you analyze all the data and applications in your current environment, consider how they can be consolidated and improved to ensure that your new SharePoint 2013 environment is optimized from the start. In addition, having to manage the migration of disparate SharePoint versions and other legacy collaboration systems places a heavy burden on IT staff and complicates the migration process considerably; consolidating those systems now, before the migration, will make the migration process simpler and faster, and therefore reduce costs and risk. What to consolidate Multiple SharePoint installations SharePoint’s an easy system to start using. As a result, you may have several independent islands of SharePoint scattered around the firm. Round ‘em up! Aggregation will yield immediate benefits for both end users and IT, and it will reduce the number of moving parts during your upgrade. Multiple SharePoint installations can also be the result of a merger or acquisition. SharePoint has achieved 67 percent enterprise adoption, according to Microsoft data released at SharePoint Conference 2011. With that high adoption rate, it stands to reason that a merger or acquisition today has a high likelihood of leading to at least two separate SharePoint installations. If you haven’t consolidated those SharePoint environments yet, do so now, before your migration to 2013; it will make it easier to forge shared team processes and identities, and reduce the number of places users need to browse to find good content.

Finally, if you have multiple versions of SharePoint in your environment, consolidation into SharePoint 2010 offers another key benefit. For earlier versions, there may be no direct, in-thebox upgrade path to SharePoint 2013. But the upgrade from SharePoint 2010 to 2013 will be directly supported by Microsoft, so consolidation into 2010 now will best align your enterprise for the upcoming 2013 upgrade. Other legacy content In addition to multiple SharePoint installations, look for other legacy collaboration platforms within your environment, such as Windows file shares, Exchange public folders and Notes applications. Consider whether you can centralize the content into SharePoint 2010, being sure to take full advantage of useful SharePoint features such as lists, libraries, metadata, content types, and workflows. Doing so now will ensure a much smoother upgrade to SharePoint 2013. Moreover, you’ll be giving your users a chance to get used to the new, unified structure of the data before they take on the task of learning the new SharePoint 2013 features and interface. Example For example, you might have discovered that you have four major sources: a file share, a SharePoint 2003 installa-tion that supplies employee information, a 2007 installation that does departmental and divisional portals, and a 2010 implementation doing search and some personalization. Migrating that content from its current diverse locations to SharePoint 2013 is a daunting prospect, isn’t it? But if you look more closely, you may see pieces of taxonomies in different areas, such as standard columns on a 2007 site, that could be used more broadly. Content from the file shares might well duplicate or complement information already in one of the SharePoint installations. Consider how much cleaner your environment would be if you consolidated all appropriate content into

Share:

11

SharePoint 2010 now – and therefore how much complexity would simply disappear from the migration project. Consolidation options Once you have decided to consolidate content, you have two choices: you can leave everything where it is and run four or five separate migrations into the next platform, or you can consolidate now and do one upgrade to the next platform. My usual recommendation is to consolidate now, for several reasons: • First, users and admins alike will start enjoying the benefits of the centralization immediately, in your current SharePoint environment. • Second, everyone will have a chance to get used to the new structure and organization of content before they take on learning the new features of 2013. • Third, the consolidation work will be easier if you do the work on a platform you’re already familiar with. Share-Point 2013 will be new, with plenty of new functions to master. SharePoint 2010, on the other hand, has been out for over two years, so IT organizations are largely acculturated to the best practices for it. It will be simpler to transform your information architecture on a mature set of administrative interfaces than while you’re learning your way around the new version. • Finally, the migration itself will be easier and cleaner, since you’ll be migrating only one environment instead of performing multiple parallel upgrades.

Of course, individual knowledge workers absorb change only at a certain rate – you can’t change too many things at once. The brave new world of the SharePoint 2013 interface and features will require careful planning for good adoption. But a migration necessarily involves moving content from source to target, so it’s perfectly appropriate to consider carefully which target you want to move each piece of source content to – including a new unified target. Thus, migration is an opportunity to transform the structure of your data and get your classifications right.

In addition to multiple SharePoint installations, look for other legacy collaboration platforms ... that can be centralized into SharePoint 2010, being sure to take full advantage of useful SharePoint features.

Conclusion

About the Author

SharePoint 2013 will offer a great range of new capabilities that will offer compelling reasons to upgrade or migrate. You can begin to prepare now to make your move to the new platform as smooth and easy as possible. Five key steps are to establish governance; move to code-free customization; inventory your current environment; externalize little-used data; and consolidate content. You’ll get immediate benefits in your current SharePoint environment and be poised to adopt SharePoint 2013 as quickly as possible.

Chris McNulty is a strategic product manager for SharePoint Solutions at Dell, where his responsibilities include the strategic product direction for Dell’s SharePoint solutions. Chris is a Microsoft Certified Technology Specialist (MCTS), Microsoft Certified Systems Engineer (MCSE), and a member of the Microsoft Solutions Advocate and MVTSP programs. A frequent speaker at events around the U.S., Chris is the author of the “SharePoint 2010 Consultant’s Handbook – Managed Metadata Service,” and blogs at http:// www.chrismcnulty.net/blog and http:// www.sharepointforall.com. Prior to joining Dell, Chris led the SharePoint consulting practice at KMA, a New England-based Microsoft Gold Partner. He holds an MBA in investment management from the Carroll School of Management at Boston College, and has more than 20 years’ experience in financial services technology with John Hancock, State Street, GMO and Santander.

Share:

12

For More Information © 2012 Dell, 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 Dell, Inc. (“Dell”). Dell, Dell Software, the Dell Software logo and products—as identified in this document—are registered trademarks of Dell, Inc. in the U.S.A. and/or other countries. All other trademarks and registered trademarks are property of their respective owners. The information in this document is provided in connection with Dell 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 Dell products. EXCEPT AS SET FORTH IN DELL’S TERMS AND CONDITIONS AS SPECIFIED IN THE LICENSE AGREEMENT FOR THIS PRODUCT,

About Dell Dell Inc. (NASDAQ: DELL) listens to customers and delivers worldwide innovative technology, business solutions and services they trust and value. For more information, visit www.dell.com.

If you have any questions regarding your potential use of this material, contact: Dell Software 5 Polaris Way Aliso Viejo, CA 92656 www.dell.com Refer to our Web site for regional and international office information.

Share:

Whitepaper-5waystoPrepareforSharePoint2013-US-TT-12-07-12

DELL 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 DELL 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 DELL HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. Dell 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. Dell does not make any commitment to update the information contained in this document.