[O365] Migrating InfoPath forms to Office 365

Technical / December 17, 2015 / Jasper Siegmund / 2

For a client, we’re currently migrating a lot of their existing on-premises SharePoint 2007 and 2010 solutions to Office 365. All of these are customized (the easy work has been done already), so that sort of guarantees running into stuff that is not Office 365 – ready. One category of items are InfoPath forms and I noticed there’a quit a lack of blog posts on this topic so I thought I’d try to fill that gap a bit.

For those not aware; Microsoft has officially said InfoPath doesn’t have a future. Even though they recently extended support for it, you can assume that there will not be any further improvements / updates to the product. Best evidence of this is the Infopath team at Microsoft being non-existent (at the moment). Still, instead of finding a different solution, you can very well port your existing forms to Office 365 (to some extent, more about that below). That might be worth while until Microsoft announces an official roadmap for forms in SharePoint / Office 365.

First of all, let’s take a look at the different kinds of forms we can encounter:

1. Forms without codebehind
   If you come across one of these, you’re in good shape. You should be able to easily migrate this to the other side because InfoPath is still supported. Your migration tool might support doing this, or you can simply open the form in InfoPath 2013 and publish it to it’s new location. This process is relatively painless.
2. Forms with codebehind (sandboxed)
   For the forms with codebehind, there are two different types; sandboxed and fulltrust. The ones with sandboxed code are the easiest to migrate. Sandboxed solutions are in the same boat as InfoPath: supported, but not being actively worked on any more. So eventually you will need to do some rework on these, but for now you’re good. Note there are some considerations to take info account for sandboxed solutions, but for existing forms these already have been considered I would think.
3. Forms with codebehind (fulltrust)
   Now the “fun” begins. As you probably know, fulltrust code is not allowed within a SharePoint Online / Office 365 environment. So by definition, you cannot migrate these. What are your options then? Well you could inspect the code to see whether this couldn’t have been done within a sandboxed solution. If the code is only fetching or writing some data from the site (collection), then there’s a good chance you’ll get this to work within the sandbox limitations as well. If the forms code is doing more than that, it might become more challenging and you might have to conclude InfoPath isn’t an option any more. There are some alternatives I’ll list below.

Workarounds

If you’re anything like me, you’ll probably try to find some workarounds. But I’ll have to disappoint you up front, there aren’t any good ones. Using CSOM code from within the sandbox? Nope. Calling into webservices to do the work via CSOM or REST? Nope. JavaScript? Nope. That’s just not how InfoPath was originally designed and  you’ll have to do with that. Should anyone have discovered any clever workaround that does work, feel free to post that in the comments below!

Alternatives

You do have some alternatives. Let’s start by saying that these alternatives, as far as I know, all require you to recreate the entire form from scratch. That sucks, but it’s the way it is.

• HTML and Javascript
  Pretty much the most versatile option you have. Create a browser based form with JavaScript acting as codebehind and you’ll be able to do everything a browser does. Deploy as an add-in or via a deployment framework and you’re good to go. Major downside is that your business users will not be able to change things, something that made InfoPath pretty popular.
• Access
  Access? Whut? That tool from the past? Well if you take a good look at access today, it’s definitely not what it was back then anymore. With access you can now create web based applications that feature… forms! I must immediately add that I don’t have any real hands-on experience, but there are some blogs to be found when you Google for this.
• Third party solutions
  Of course several third parties tried stepping into the gaping whole that InfoPath left. None of these was really successful, at least I don’t come across them very often. Examples are the forms solutions of Nintex and K2. And if you search for “Forms” inside of the SharePoint store, you’ll find a few more. None of these look or feel very mature in my opinion, but you might want to check them out since these are continuously under development too.
• SharePoint
  Ah yes, let’s not forget the obvious one! SharePoint itself of course. You might want to just drop some of the codebehind functionality you had and revert to using a standard SharePoint list form instead. You could leverage external event receivers and/or workflows to pick up the input and do things with it. JavaScript can be used to show/hide certain sections of a form, which always has been a popular feature of InfoPath. Ideal? No. Watertight? Definitely not. But it might be workable depending on your requirements.

Hopefully the above info can assist you in getting those pesky left-overs from you on-premises SharePoint environment into the cloud. Feel free to ask any questions below or add your experiences migrating InfoPath to different forms solutions.

PS: tonight’s DIWUG features a session on InfoPath replacements. I deliberately published this post before that so you don’t think I stole the guys’ content 🙂 If something useful flies by, I’ll update this post accordingly (including credits ;))

#InfoPath, #o365, #o365dev, in

Jasper Siegmund