SharePoint development past and "future": how to keep calm?

Question

I'll do my best to not turn this question to an "opinion-based" one, but it's a great effort for me!

SharePoint 2003: the story begins

In the beginning (SharePoint 2003), we could develop Web parts and event handlers.
We could do that from Visual Studio, and even if there was no integrated deployment mechanisms, we only had to deal with a very few XML files and 2 or 3 commands with stsadm to package and deploy.

SharePoint 2007: the farm solution model

Then came SharePoint 2007: it brought a mechanism to deploy and update properly artefacts (features and WSP solutions).
A lot of new artefacts was also made available: custom actions, control templates, feature event receivers, content types, ...

There was no good tool in Visual Studio initially, but we could create a simple "make file" to automate the build without external tools.
Or we could use WSPBuilder, from the community, that was perfectly integrated into VS (even though it had some drawbacks).

Finally came Visual Studio 2010 where everything was directly integrated: a new project type to support almost everything we could do with SharePoint + complete package generation + debug tools + all from the UI.
We were efficient, SharePoint was an accelerator for developments.

SharePoint 2010: sandbox solutions

And then SharePoint 2010, the best SharePoint version IMO (we had all the best from the product, it was stable and reliable, users were efficient with a consistent UI accross the Office range, and no crappy trendy features in it).
The WSP package concept was there to stay. Developers knew it and were efficient coding in C#/ASP.NET (and a bit of XML if they wanted).
Only known/mastered technologies. Very few bugs.

Oh, yes, there were bad applications developed in SharePoint. But less and less. And applications were actual applications to deliver actual value to businesses.
If you had enough experience (let's say 1-2 year) with SharePoint development, you could be very proficient and deliver a real-life professional application in a few days or weeks, much faster than with pure ASP.NET.

The model was good enough for Microsoft to create the "sandbox solution" concept. It was a step to the cloud: Microsoft didn't want developers to deploy crap on their servers, but they also wanted to allow customizations.
The idea was not that bad, since sandbox solutions allowed developers to re-use the exact same concepts (WSP, features, artefacts, server-side API) but with some boundaries to avoid messing the cloud servers.
At that time (3 years before add-ins), Microsoft clearly promoted the sandbox solutions as the new black.

2013: The Cloud.JS

And then came the Cloud/App/JavaScript/ILoveMummy.JS blast: SharePoint 2013.

WSP were evil.
Sandbox solutions were eviler than the evil.
Apps were the new black. But not a good name, don't know why. Let's say Add-ins instead (to add more confusion).

Forget everything you learned.
Forget being efficient coding in C#.
Forget all known concepts about SharePoint.

Learn about slow IFrame with cross-domain calls to be workarounded with proxied calls, Internet Explorer security zone problems, hidden "app-web", authentication mechanisms, app manifest for permissions (Full access not being allowed in the Microsoft official store...), DNS configuration for wildcard domains, SSL certificates for wildcard domains, AAM for wildcard domains, JavaScript with no Intellisense, debugging with F12 and alert, recreating the SP chrome artificially, loosing the navigation, who pays for auto-hosted apps?, what's the difference between a provider-hosted (CSOM) app and a provider-hosted (oAuth) app and a provider-hosted (high-trust) app?, client-side Intellectual Property protection, etc.

Only to explain the authentication mechanisms to good developers, I spend 2hrs in a training class! How can this approach be fast when you draw 10 arrows on the paperboard just to show how the user is authenticated with your app?
Microsoft even announced quickly the "auto-hosted" model was to be retired a few months after it was released.
Some software vendors tried to port their WSP applications to the new app model: they had to cut half the features of their products, or more.
In 4 years, 1135 apps have been published in the official store, including a lot of "hello world" apps from testers, weather widgets and carousels.

But that was definitely the way to go, as per Microsoft. They also convinced a lot of other people to push evangelisering materials. One among 1000s (note: I challenge every "reason" from that article).

My first question is: in 4 years, did you ever see a complete business application properly deployed in the add-in model?
If yes, what was the cost of the development compared to other technologies (pure ASP.NET, pure PHP, "old-fashion" WSP...) in your opinion?

As per this recent post from @PatMill_MSFT, we even learn from Microsoft that "5000 lines of pure js is a lot".
Also, apparently no-one can answer a simple question ("simple" in the sense "could be easily solved in the old times") about authentication delegation and access to data in Office 365 (I raised the question on this site, but also to a lot of consultants, Microsoft employees, etc.: noone could provide me with a solution).

My second question: should I conclude that JavaScript add-ins are for applications less than 5000 LoC? Because (and I know the LoC indicator is just an indicator, not a definitive metric) most real-life business applications are much more than 5000 LoC!
How are we supposed to develop complex JavaScript solutions if we consider 5000 LoC is a lot in the SharePoint-hosted app model?

2016/2017: SPFx "release candidate"

But that's not the end of the story.
We now learn that "There are a couple of downsides though" with add-ins. No kidding?!
So, something new to overcome the situation: SPFx!
OK, let's see.

JavaScript is still arround, but no more IFrame, sub-domain, etc. Good.

Instead: NodeJS, Gulp, Yeoman, React, WebPack, etc. And no more integrated environment like Visual Studio. So old-school. All MS-tech developers know/have Visual Studio, so let's dismiss it now! To install a clean dev environment, you have to setup 5 or 6 modules, use many command lines, mind the versions ("If you have NodeJS already installed please check you have the latest version") and pray for everything to be compatible with the latest versions. And they don't even mention how to develop in a team, how to easily version-control your sources, etc.

Building a "Hello World" Web part may take a day to read the articles, setup the environment (because it's not Visual Studio, remember? so, setup a new complete environment) and follow this basic tutorial. Hope you know NodeJS, Gulp, Yeoman, Visual Studio Code, JavaScript, React, TypeScript, HTML, CSS, JSON, and a bit SharePoint.
Also hope you don't mind your Web designer cannot access the HTML code easily.
For a "simple" old thing such as localizing your solution, something that should have been solved decades ago: nothing to help you, apart from reading a 33-page article that explains you you have to maintain a bunch of different files in sync manually. And that's only one example among many.

Let me skip the still-not-solved-even-with-the-amazing-Yeoman-tools versioning problem: SPFx is not even the announced silver-bullet even in that advertised area (I spent 2hrs solving problems while upgrading from SPFx 1.3 to 1.4).

And I don't even mention the SharePoint API mess: the server-side API (probably too old-school to mention, but still), the SOAP Web services (same remark), the .NET client-side API, the JavaScript client-side API, the REST API, and now the brand-new Graph API.
Oh, wait, do we count the brand-new Graph API while it's not that compatible with the brand-new SPFx?

So, my third question: if you had to create a new application for a customer, "from scratch", would you go with the "new shiny" SPFx tools?
Do you think developers are efficient with it? Is it sustainable? Are your teams comfortable with all these "technologies"?
And an opinion-based one: isn't Microsoft goind crazy with SharePoint development, as I think? Are we supposed to be confident we have finaly found the (SharePoint dev) silver-bullet with SPFx?

---

EDIT: some more details about my thoughts, following some points raised in answers below

I'm not afraid of changes. I'm afraid we are forced to use new technologies just for the "fun" of using "edge" technology and fancy names because a new Product Manager at Microsoft decided to upturn the tea table.
It's like if the "Cloud" is encouraging Microsoft (not only) to trash all the long trust-relationship with developers in order to please the marketing guys.
(I see at least 3-4 reasons for that: 1. It's technically easy for MS to push and test changes to the Cloud, so they try a lot instead of long-term thinking ; 2. They're not a real leader anymore in the industry, so they run after the newest technologies just to "stay in" ; 3. There's more turnover in enterprises ; 4. Managers are less and less technicians)

Releasing (and soon after dismissing) new technologies without a long-term vision may not be what we expect from a dev company like Microsoft.

Changes is good when it brings actual value.

As a developer, I don't have to accept all changes without questions. My job is also to be efficient, to challenge new technologies, and to help my customers building the best software (i.e. bringing value with the cheapest, maintainable, sustainable, evolutive piece of software...)

What's the value of spending 1+ day to setup/understand your dev environment for your team while all developers are familiar with Visual Studio? A dev environment that may break as soon as a new version of one of the involved tools is not supported anymore/releases a new non-compatible version/is abandoned for another one? This is highly probable when the tools are not owned by Microsoft nor built with SPFx in mind!
What's the value of running 5 or 6 modules before packaging an app if a failure may occur at every step?
I meet a lot of developers in my work: I've never seen a developer (even a young one, or even an old one, choose what applies best for JavaScript) being happy with a JavaScript project. Have you seen a lot of them? Is an unhappy dev more efficient?

And above all: how can we be confident we're now with the "good" (i.e. lasting at least 2 or 3 years!) framework while so many concepts/frameworks that were known to be the silver-bullet are now ~dead (sandbox solutions, autohosted apps, Graph API being non-compatible with SPFx, Angular 1, Grunt, XML, SOAP, Apps and IFrames, SharePoint ribbon, UI tiles, SP list dialog boxes... to randomly name a very few of more or less importance).

And in response to @florian-leitgeb:
Maybe the young developers can't get the big picture of these constant new-framework/new-tool-on-the-block changes. But imagine: can you say "go with the flow" to someone who invested in Silverlight or auto-hosted SP Apps or XNA or Angular 1 or InfoPath or Workflow 1.0 or even SP REST (Graph is the new kid here)? What are the odds Gulp and SPFx won't be that hype in 2 years from now? What will I tell to my customers when they understand the great-tech we used 2 years ago is obsolete and the project has to be re-booted? Microsoft used to "develop things" in an integrated and long-term way... not anymore IMO.

Answer 1

My observations (answers at bottom):

If this is too long then just read the headings

Developer => Accept change

If you want to stay calm and not have your world changed all the time, then maybe a job as a Software Developer isn't the right for you unless you want to maintain old legacy applications.

• Cobol hasn't changed much lately.
• Companies/Application staying on SP2007 hasn't changed much lately.
• A carpenters job hasn't changed much lately.

But working with the latest technologies will/should always mean change.

SharePoint Developers has always wanted to get up to date

As long as I've been in the SharePoint area the developers have always asked why they couldn't work with the latest technologies:

• In SP2003 they wanted real ASP.NET not that strange SP fake
• Later the wanted ASP.NET MVC not that old WebForms.

Microsoft/ASP/SharePoint has resisted change too long

Microsoft/ASP/SharePoint has way too long tried to protect the developers from change:

• Coding ASP.NET WebForms should be just like coding WinForms, no need to learn web
• Coding Async JavaScript is hard, we'll hide that in UpdatePanel
• Coding JavaScript/REST is hard we'll hide that in JSOM

If you want to stay at the edge now is the time to wake up

Microsoft/SharePoint has finally accepted that if they want to be a player in web/intranet then it means playing by the webs rules.

This means that if you want to stay on the leading edge, then you should learn the tools the web world has been using for years:

• Node.js, npm, ASP.NET Core
• Grunt, Gulp, Webpack
• ...
• VS Code, Atom, Sublime
• ...

The jump to all these technologies is huge due to the well-meant, but harmful protection in the last section.

The leading edge will make mistakes

Staying at the leading edge means that you'll run down some dead ends and have to restart when we as a community becomes wiser

But if you don't want to stay on the edge then just ignore it

But there is nothing that dictates that you should stay on the leading edge if you don't want to.

• MS has promised classic pages will stay (but not for how long)
• It seems that "old" web parts (Full Trust/Add-ins) will be supported on modern pages

Office 365 may force you to be more on the leading edge than you want to, but then there is on-premises.

Note that SPFX isn't released yet, this is just the new Microsoft talking about things to come.

Disclaimer

All of this is easy for me to say as we in my company already switched to the new way of developing for SharePoint more than a year before SPFX, so we had time to learn the new tool chain at our own pace.

But I'd kick and scream if you tried to force me to use the full Visual Studio and ASP.NET X.X

Answers

1. Have you seen a large add-in.

No I haven't tried to make a large add-in, the stuff we make integrates with the SharePoint UI and add-ins is not good for that, so we did something similar to SPFX

2. Is 5000+ loc suitable for JavaScript

If your large app isn't modulized then I don't care about what language you've used.

If you split it up then modern JavaScript/TypeScript is as good for this as any. Or maybe try Elm.

3. If you started now would you use SPFX

For all of the things integrating into SharePoint definitely YES, for a lot of the other stuff I'd put it in a AzureAD app outside SharePoint, just have permissions to SharePoint, Graph, ..

Notice that SPFX is the first time in a very long time that the SharePoint team is using the same technology that they want us to use. They didn't release any Sandboxed solutions or Add-ins.

But I'd still code it in TypeScript

Answer 2

So, I'll wade into this discussion. Apologies for the wall of text. Some background - I was a developer in CMS 2001/2002 before we joined the SharePoint group in 2003. I've build on top of the core SharePoint codebase as part of the publishing features, taxonomy, etc. I'm super familiar and comfortable with server solutions and how to extend SP on the server. I'm in charge of the dev team that is creating SPFX.

The server model worked (and works) great on-prem. Coincidentally, it was also the model that was used internally by the product teams. As James Love mentions above:

"There are lots of bits of the SharePoint API that are amazing for enterprise applications - Timer Jobs, Content Databases, security model, authentication system, claims providers. All in the one package"

As you mention, 2010 was a great point in the development model. There was great VS2010 integration, it was all the same tech (C#), and the path had been blazed for a few releases by external developers and internal developers running the same extensibility model.

However, the server model doesn't work in the cloud - full stop -

"Microsoft didn't want developers to deploy crap on their servers, but they also wanted to allow customizations."

is not exactly the wording I would use, but the messaging isn't that far off. That left a few different approaches - Sandbox Solutions, Add-Ins (iframes), and front end code via jslink+SEWP+ScriptLink. Now oddly enough, the approach that got the most traction here was the one with the least amount of support - front end code. The truth is, a lot of people don't like the hassle of iframes (you have a laundry list of hurdles), and sandbox solutions didn't really work. Iframes are great and necessary for certain scenarios (I don't really know who made this code, and I don't really trust them, but I'm OK with running it in some isolation) but a lot of people know who the developer is. It's the person two doors (or cubes) down. (small aside - Add-Ins, as I mentioned, make a lot of sense in some scenarios. We are planning on continuing to support and improve them over time).

Which is why a lot of people wound up at jslink / scriptlink / script editor web part. It avoids a bunch of the headaches around iframes (security, perf, different domains, etc.) and is relatively performant. Around this time came a push to revamp the UX of SharePoint, and move off of the asp.net rendering pipeline and push it to the front end. We wanted to get back into the point where 1st and 3rd party developers would use the same (or similar) tech. Enter SPFX. The first shipping app / experience based on it is the modern page, and the first extensibility point is the webpart. The running code for 1st and 3rd parties is effectively the same (the 1st party ones have some extra telemetry / logging, but that's about it). When 1st parties need additional functionality, 3rd party developers get it, and when 3rd party developers need additional functionality, 1st party developers get it. All the energy goes to the same place.

Now the tooling is certainly different - there are no two ways around it. The fact is that VSCode is where more of the client side development is focused as far as Visual Studio is concerned, we don't want to do large scale development projects in pure js (enter TypeScript - sure you can write 5000 lines of pure js in notepad without compile time checking, but would you want to?), and open source tooling is where the majority of client development takes place. We felt it was a better choice to go where the people (and knowledge) are, leverage the tooling that exists and contribute tooling where we see a gap (https://github.com/Microsoft/web-build-tools).

However, it's not our goal to introduce change for change's sake. We want to be able to allow you to leverage your domain knowledge where possible. The REST calls are still the same REST calls, the feature XML will be as similar as possible, we'll still leverage the app catalog. Additionally, because we are trying to leverage as much as we can, improvements to the core tech should improve existing functionality as well.

I completely understand that there is hesitation and uncertainty around SPFX. As you show above, the track record on non-server extensibility has been dodgy. I feel the best way to remove that is to ship the first iteration (web parts), get feedback and improve it, add additional extensibility points, refine them, refine the tooling, etc. SP2010 was built on numerous years of development. V1 of SPFX won't have that degree of tooling and polish out of the gate, as people want / need something sooner than that. The more people use it and provide constructive criticism / feedback / suggestions, the better it will become. Our goal is for solutions written today on SPFX to continue to work for the next 5-10 years. We've made that an input into the framework itself, so that we can handle breaking changes in the future while still maintaining backwards compatibility. I'm sure we'll run into some horrible issue in a couple of years (browsers deciding to not support XHR requests or something), but that's is our stated goal.

One quick aside - it's worth pointing out that the server endpoints available on SharePoint and O365 are separate from SPFX. So for the comment around accessing the Microsoft Graph (and really, any O365 endpoint) - auth currently sucks - it's like being back in iframe land. Streamlining that is something that will benefit the entire SharePoint browser "app" itself, independent of it running SPFX, SEWP or any other javascript. We're working on making it a) possible and b) straight forward.

We're not malicious, we do care how efficient you are (because that efficiency effects us - we're using the same tools).

OK, that's probably enough for now. Hopefully I've shed at least a bit of light on things.

Answer 3

CSOM is the best thing to happen to the platform. It lets us run code where ever the hell we want, how we want. The REST API (not ListData.svc, that should never have made it into the release) took it a step further and allowed client side code to be easily written in JavaScript too.

The problem with SharePoint solutions was the upgradability of the solutions with each major release. I applaud Microsoft for finding solutions to help with that, and the only things they explicitly deprecated from any of the models was autohosted apps, and UserCode within sandbox solutions. Everything else in all other models is still supported as far as I remember.

One opinion I have is that MSFT seem to be pushing the idea of building LOB applications in SharePoint (your 5000LoC applications). Which is a really, really daft idea imo. Sure, use SharePoint for some data storage (because lists are crap when it comes to lots of data).

But given how often SharePoint changes as a platform, in particular the UI, you just cannot build a LoB application with a usability and interface guarantee for the usual lifecycle of these types of applications. The systems we build now are replacing systems probably built in the late 1990s in Delphi or Visual Fox Pro, where the userbase is nice and familiar with their interfaces and how they work.

Build a "PowerApp" that's nice and trendy and gives users a way to input data via a smartphone - great, but there's no guarantee Microsoft wont' change something with how that works, or the user interface controls at some point down the line in a couple of years that requires user re-training. But I guess that's the trade-off between an app that costs £10k to build vs one that costs £100k.

Answer 4

At the end of 2013, I decided to dive into the SharePoint app world (Oh, they are now called add-ins) and did few samples and shared my learnings. I had added a disclaimer to the blog:

I did not make any production apps as I am yet to get allocated on a project which uses SP 2013 apps

More than 3 years down the line, the disclaimer is still true in my case. Not that I have moved into some new technology, I am still a SharePoint guy and work on SharePoint projects. But most of the clients have SharePoint on-premises and why would they want to go for SharePoint add-ins (hey, we have SPFx now).

In between I did get to work on couple of Office 365 projects, but here again it was lot easier and time saving to use the front end code using jslink, CEWP, SEWP, etc; + XML file deployments using Sandbox solution.

Answer 5

The amount of change we've had to deal with in the SharePoint Development space in the last 12 years has been exhausting. I've lived through it and will tell you it's just hard for management and users to accept we need to keep learning completely new frameworks, changing approaches and migrating solutions. I've had solutions that have been on every single approach mentioned .. farm solution > sandbox > Client side object model and now we can't run in Modern Pages. We've been playing with SPFx and IMO it's so damn different and so bulky with all the extra files that need to be deployed. Also, some of these roll-outs seem rushed and incomplete. If I've learned anything it's to wait for things to settle down. There are things about SharePoint (specifically SPO) that are incredibly backwards now. I find it hard to sell SharePoint to my users mostly because of these terrible short-comings:

• SPO Lists over 5k items is STILL A BIG ISSUE
• Still no easy way to customize or inject CSS and JS into Modern Pages
• Power BI Licenses for o365/SPO are stupid. All users need Pro licenses??
• SPFx development seems so bulky and cumbersome. It's also so new and different it's impossible to find developers or experts. Most power users on SP are looking for Rapid and Code-less solutions. Keep it simple and give us a built in IDE on o365. Less tools and less steps is MORE.
• No real Form and View development tools in SharePoint. They abandoned SharePoint Designer, InfoPath and now Access web apps and offered no viable alternative. PowerApps is so far from there yet and does not appear to be the answer.
• Easy Azure integration for SPO is not there yet. Might be our best option for development but it's true and full development. Likely where we will go.

We will wait and maybe we can skip some of the pains and missteps.

Answer 6

That's a great discussion out here! Let me put my 50cents. A lot of different topics are discussed, I have a lot of different thoughts and don't even know how to structure them. I'll try.

I think there are few reasons why Microsoft invent new approaches. And the main reason is moving to cloud. Consider image from here - SharePoint converged code base. They have plans to merge the code and one day in a future we will see the message from Microsoft - "Sorry guys, on-premise SharePoint deprecated".
But it's not possible to use farm solutions for manipulating with SharePoint Online, that's why apps, csom came into play. Miscrosoft tries to find the right and good way to provide us with an options to customize SharePoint Online, but that's hard thing to do, that why some attempts are failed or have some drawbacks (auto-hosted, code in sandbox solutions, iframes, etc.). That's like windows vista. From the other side the good point is that MS still think about developers and tries to find a way to do customization more efficient.

Of course all this changes are annoying. Especially when they are deprecated in a few years after announce. How to deal with that? You have either live with that or switch to new technology which is more interesting for you.
Is it good to move everything in a cloud? I think yes, because it's a tendency nowadays, it gives easier management, setup and configuration. less cost for IT infrastructure.

Also the fact that MS tries to invent something new and tries to follow modern tendencies is also good. I can't imaging if in 2017 we are developing ASP.NET Web Forms pages for SharePoint farm solutions. Everything is evolving and evolving really fast in recent years. How many js libraries you can name in 2007? I can say - only one, jquery. And today? From my POV staying at the same place today is like a death. And hopefully MS doesn't stay.

Also some thoughts on too frequent changes. I spoke with different web developers from js background (nodejs or web frontend). I'm also doing a lot of web frontend development. Today they are having the same problems with interoperability, numerous different modules and libraries, compatibility issues, etc. That's a total nightmare actually - just read this article. But you have to follow if you want to be on top.

For the questions:

My first question is: in 4 years, did you ever see a complete business application properly deployed in the add-in model?

Yes, I developed such application for SharePoint online - azure web app, jobs, storage, remote event receivers. The app helps generating different kind of documents and distributing on other sites. The project duration is around one year.

should I conclude that JavaScript add-ins are for applications less than 5000 LoC?

I don't think so. My POV - just write good, maintainable, modular javascript (typescript) and you are good to go.

if you had to create a new application for a customer, "from scratch", would you go with the "new shiny" SPFx tools?

If requirements allow me to use SPFx in order to solve any particular task, definitely I will go ahead with SPFx. I found SPFx might be extremely hard to learn without good understanding of basic concepts - es modules, typescript, webpack. Having all that background and angular 1 & 2 in addition I like the idea behind SPFx and will use it.

Answer 7

but isn't this issue no different than what we all have experienced for some time now, no matter the tech stack, framework, tools, etc we work with? I know for me i have been frustrated with this issue ever since the days of java bloat, oracle nightmare APIs, javascript, browser incompatibility, etc. I'm sure you have your own nightmare stories, but the point is we've all been dealing with this for years, and it boils down to a few simple things:

1. we are drawn to new tech, and we're addicted to it. why? because a) we're nerds and this stuff is cool; b) we avoid reinventing the wheel and rewriting takes longer; c) if we hear it's cutting edge then we have to jump on it to keep up with the joneses; and d) sometimes -- and this is very rare IMHO -- it actually does do something truly innovative
2. integration has become a nightmare. there are too many frameworks, disparate apps, technologies etc. and the chances of all of them working together out of the box has become almost nil. anyone remember what a challenge it was to do a code port to a new platform? i do. we recompiled Pro*C from an old sun box on our new AIX system. well, that was quite a challenge, and it required regression testing every single scenario in the app. huuuuge effort for the entire project. but think about it; that was just two moving parts -- the OS and a language. imagine if that had been 20, or how bout 30? and if that is not risky enough, imagine if each one of those parts was individually changing versions every, oh i dunno, 6 months? i think you see the problem. just as a thought experiment, do a google search for latest tech and pick the first dozen things you see, then pick any two of those. now google those two and the word "problem" and just look how many posts come back. convinced? well, any CM person worth their salt knows how bad this has become. and sadly a lot of them have just kind of given up fighting against the tech addiction of us devs. but when your system is constantly broken, constantly has recurring bugs, is unstable and needs you to baby it and run to the rescue all the time cos it needs yay another "critical" update, just remember that CM was right. integration has become a nightmare.

so what is the answer? it's simple. just say no. hold back. do not jump at the new technology, be skeptical. favor system stability over new tech, tell your boss about risk, hire a CM person who will not let you release some wiz-bang new JS library into prod until the ENTIRE affected scope has been tested. don't know what that means? well, hire a tester who has worked on an actual legit project, with proper Process, and tell your project management you want everything you do to go through testing before getting pushed to prod. it's really that simple. you either a) go fast and furious, imagining you're vin diesel (meanwhile all you're really doing is driving 120 MPH but zigzagging all over the place), or you b) think like an engineer and be mature, conservative, deliberate, and smart about things. and yes, this means -- gasp -- progress might be slower and won't be as sexy. but unless you are doing some snapchat project that, in the scheme of things really does not matter if it breaks, this is probably the way you should go. so get your sharepoint 2003 up and running, then mess with it only when it is truly broken or needs an enhancement. and when they scoff at you for not going to the cloud, ask them to tell you ONE specific user requirement that absolutely could NOT be done without the cloud, and ask them sarcastically how on earth we ever landed on the moon without it.