No matter if your next SharePoint environment is on-premises or on SharePoint Online, the new app model is beyond doubt the preferred way to develop customizations in the future. With this change developers now face the challenge what to do with their "old" SharePoint solutions written in full trust code. In this session you will learn what this transformation means, how this process looks like and how you can analyze your existing SharePoint farm solutions, discover roadblocks and align your strategy and decisions with Microsofts guidance.

1. Transforming SharePoint Farm
Solutions to the App Model
Matthias Einig, MVP
CEO RENCORE AB
#spshelsinki

2. SharePoint Saturday Helsinki
Thank you to our sponsors!

3. Who is that guy?
matthias.einig@rencore.se
www.matthiaseinig.de
Matthias Einig
CEO, SharePoint MVP
Stockholm, Sweden

4. The Basics

5. Full Trust Code vs. “App”
Package/Application/Code that uses
• Server Side Object Model
• Declarative Code
• Infrastructure specific components
(e.g. HTTP Handlers)
Package/Application/Code that uses
• Client Side Object Model / REST
• Could run with Office365
• Runs off the SharePoint box

6. What is
“Transformation”?

8. Magic

10. What is transformation?
Transformation != Migration

11. What is transformation?
Marketing buzzword for:
“look at what you have”
then
“implement from scratch”
while
”re-­‐using concepts, ideas and data”

12. Why?

13. Why would you transform?
ž Moving from on-­‐prem to Office365 or Hybrid
ž SharePoint version update
ž Changed / New Requirements
ž Cannot start on a greenfield (time, money, complexity)
ž Maintenance problems caused by customizations

14. How?

15. Replace / gradually update
existing FTC components
Re-­‐use
code / data structures / solution concepts/
integrations
How would you transform your code?

16. Major Changes

17. Major Changes
ž No SSOM, use CSOM/REST
ž Avoid Feature Framework
ž Avoid CAML (WebTemplates, Content Types, etc.)
ž Avoid MasterPages
ž Minimize Branding
ž Run code outside of SharePoint (Client, Provider)
ž Consider SharePoint/Office365 as a service

18. CAML == BAD
Custom Web Template
onet.xml
X feature activations
onet.xml
X feature activations
onet.xml
X feature activations +2
onet.xml
X feature activations +4
onet.xml
X feature activations
onet.xml
X feature activations
<< Copy >>
Significant differences on the outcome unless web template
onet.xml has been updated cross site collections with the
changes which were also done for out of the box team site.
Web Template onet.xml is created by copying
team site onet.xml and by adding stapled
features to the onet.xml
Service updates for introducing new capabilities to team
sites also using feature stapling
Source: TEE2015 DEV-­‐B308
http://matte.in/TTE2015Transform

19. Reimagine!

20. Transformation != CopyPaste
ž Is SharePoint/Office365 now providing already the functionality?
ž Does your solution benefit from the SharePoint UI?
ž Are you relying on 3rd party systems?
ž Does it have to be SharePoint?
ž Are the business requirements still valid?

21. The Process

22. Assessment
&
Planning
Development
&
Testing
DeploymentReadiness
The Transformation Process

23. App Model techniques
• App Part
• Full Immersive app
• UI Custom Actions
• Remote Provisioning
Hosting
• on-­‐prem/Office365,
• Provider/SharePoint hosted
Readiness

24. “New” provisioning approaches

25. • Discuss existing solution with the business.
• Discuss the requirements with the business.
• Learn how the existing customization are used
• Decide what to keep, change and remove.
Assessment: Requirements

26. 1. Understand what customizations you have.
2. Understand what they do.
3. Understand why you have them and if you need them.
4. Understand the impact they make on the environment.
5. Understand the involved effort to transform.
Assessment: Code

27. Demo
Gather insights / Get Guidance

28. Open Source Analysis rules
• Analysis rules for MA
• Working together with the
community and MS
• Extensible
Contribute and earn
free
SPCAF Professional licenses
http://matte.in/SPCAFGitHub

29. Development
Office Pattern & Practices
https://github.com/OfficeDev/PnP
• Community project lead by Microsoft
• Core Library, PowerShell cmdlets,
samples, reference implementations
• Approved by SharePoint product group

30. Deployment
In Place
Pros:
-­‐ Less customer impact
-­‐ Less hardware and tooling require
-­‐ Can be performed with minimal
downtime
Cons:
-­‐ Harder to track progress
-­‐ Increased possibility of “Orphans”
Swing
Pros:
-­‐ Total isolation from Production
-­‐ Clean environment
Cons:
-­‐ Increased hardware and tooling required
-­‐ Increased downtime for users
(eg. Content Migration)
Source: MVA Training
http://matte.in/MVATransform

31. 1. Understand the target platform and technology
2. Understand the existing solution and
requirements
3. Reimagine and plan the solution
4. Transform
5. Deploy and Migrate Content
Summary

32. SPCAF Migration Assessment
http://matte.in/SPCAFMigrate
MVA Training
http://matte.in/MVATransform
TechEd Europe Session
http://matte.in/TTE2015Transform
OfficeDev Patterns & Practices
https://github.com/OfficeDev/PnP
Resources

33. questions?
MATTHIAS.EINIG@RENCORE.SE
@MATTEIN

34. thank you.