Sharepoint Migration

We’re migrating our users to Kinetic on the browser, and I was really hoping to avoid needing to install the Edge Agent for everyone (needed to add attachments).

Has anyone migrated from local file shares to Sharepoint? How was the migration process? Best practices? Pitfalls? Done through DMT?

Benefits (little wins that would help our users and help us convince that it’s for the best)? Drawbacks?

How is it priced? Our office users have Office 365, but we’d need access for our MES workstations as well.

I’m imagining our users revolting when all their desktop and excel links break…

1 Like

If you are not in cloud, you can use server side file attachments, they don’t require EA either

3 Likes

We did a migration of our file attachments to SharePoint in October as we were also pushing everyone to the browser and wanted to eliminate the need for Edge Agent installations on user machines. Overall, it went very well.

Before this migration, we had all of our files up in a local file server and were using the “Client System Direct Copy” transfer type. So, when a user attached a file to a record in Kinetic, the file was placed in the designated server location and that’s the location Kinetic remembered. It sounds like you may be using the link-based transfer type, though, where Kinetic is just remembering where the file they’re attaching lives, so that could complicate things.

Speaking to our migration, though, here’s how we did it:

  1. We set up the new SharePoint site and the Kinetic Attachment Type per KB0117150. We started by doing this in PILOT so we could test adequately.
  2. We performed an initial migration of files from our local file server to the SharePoint site using the SharePoint Migration Tool to maintain the folder structure. Here it is very important to check for special characters, leading spaces, etc. in file names as there can be file names that a file server will allow but SharePoint won’t, or that the SharePoint API will get confused by when trying to reach it.
  3. We used DMT to replace the file server path with the SharePoint path, which only involved changing the first part of the XFileRef.XFileName field since we maintained the directory structure when migrating the files.

Once we did this and tested, we just repeated the same process for our LIVE environment and it went pretty well. If I had caught the special characters issue ahead of time or was competent at scripting in SharePoint, I could have saved myself some manual renaming of files, but other than that we didn’t run into any real issues.

I’m not sure about pricing as our Microsoft admin handles that sort of thing, but I believe we only had about 50GB of files and that wasn’t enough for him to even question it. I’d confirm this with someone who knows Microsoft, but I don’t think 365 licensing requirements factored into it as the Azure App Registration & Certificate took care of permissions.

The biggest benefit we were seeking from this migration was getting rid of the Edge Agent and that has been great. I also find the attachments to work a bit faster with SharePoint than they did with our old file server, but that could be hardware/network related.

6 Likes

@brendanphilbin Your response is gold. That gets us moving in the right direction. Thanks! We are currently using the Link type.

@olga - I’ll also look into server side file attachments. We are on-prem. We don’t want to store them in our Epicor database, though… It’s massive enough already.

1 Like

No, it is the same shared folder but you first upload your file to app server and then app server puts it into the specified folder. So only app server accesses that folder not each user.

4 Likes

@Olga - For Server Side file attachments, what does the migration look like from Link type? Create duplicate document types that are server side, and inactivate the old link doc types?

And somehow DMT to tell Epicor that the 100k document links are now server side?

We tested the Sharepoint migration, but server side might be better for us at this point.

We’d like to allow users to update the files (like instructions or drawings), and not have a dozen of the same file uploaded with small changes.

Maybe there’s a best practices way for us to do it.

Thanks again for your advice!

1 Like

Yes, probably. Change storage type from 3 to 2.
Though server side file attachments are not supported in the cloud now.
Probably you don’t care yet.

2 Likes

If you are staying on prem and just dont want to deal with the Edge Agent you don’t need to put them on SharePoint.

We are using Kinetic web with no Edge Agent and have Kinetic serve up the SMB Shares. Give the AD Computer Object that the app server runs on access to your SMB shares and set the transfer type in CLASSICAttachment File Type System” to “File Transfer Using Service” then Kinetic will act as a SMB server proxy.

In CLASSIC “Attachment File Type System” it will allow you to put in a UNC path. If you want to have it show in the search box in Kinetic you can do some NTFS junctioning but just use classic and paste in \\server\shares\somefolder (we DONT include the trailing slash.

This setup also allows us to use an SMB Share via Kinetic with Android tablets too. Handy for taking images and then adding them to Case Entry etc.

2 Likes