This document discusses transforming SharePoint farm solutions to the app model. It notes that farm solutions use server-side object models and declarative code while apps use client-side object models and REST. Major changes in transforming include avoiding server-side object models, feature frameworks, CAML, master pages and minimizing branding. The transformation process involves assessing requirements and code, planning, developing and testing, and deployment readiness. Techniques for the app model include app parts, remote provisioning, and hosting on-premises or Office 365. Resources provided can help with the transformation process.

1. Transforming SharePoint Farm Solutions
to the App Model
#SPSBE17
Matthias Einig, MVP
April 18th, 2015

2. PlatinumGoldSilver
Thanks to our sponsors!

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

4. 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. “Will Farm Solutions be supported
with SharePoint Server 2016”
We will make though investments mainly on the
app model side also for on-premises to better align
the development story: Write once and use it cross
cloud and on-premises
Yes.
Vesa Juvonen, Microsoft

7. “Will you ever support farm
solutions in Office 365?”
Farm solutions are deployed cross SharePoint farm
and they’d impact multiple customers…
No.
Vesa Juvonen, Microsoft

8. Transforming your code

9. What is
“Transformation”?

12. Transformation != Migration

13. What does transformation mean?
“look at what you have”
then
“implement from scratch”
while
”re-using concepts, patterns and data”

14. Why?

15. 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

16. How?

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

18. Major Changes

19. 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

20. 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

21. Reimagine!

22. 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?

23. Process

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

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

26. “New” provisioning approaches

27. • 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

28. 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

29. Demo
Gather insights
Get Guidance

30. 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

31. 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

32. 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 requir
- Increased downtime for users
(eg. Content Migration)
Source: MVA Training
http://matte.in/MVATransform

33. 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

34. 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

35. questions?
matthias.einig@rencore.com
@MATTEIN

36. thank you.