Big Migration equals big headaches

So lets say you have a single site with 50 pages and you are looking to move from Content Management System X to DNN/Evoq.  Easy enough, bring up one site on one monitor and the DNN/Evoq site on another and spend a couple days copy/pasting.  Oh if life were only that simple!

We're looking at moving sites with hundreds to thousands of pages so a manual copy/paste of content just isn't going to do it.  So now I'm writing, from scratch, a migration tool to try and move content from SharePoint 2013 to DNN/Evoq.  I knew going into it that this wouldn't be easy, business make their fortunes writing these types of things, but I have pulled almost every rabbit out of the hat in making this go and I'm coming to one conclusion.

Content Management Systems don't want you to leave so they don't make it easy for you to go.  Now granted in this case getting information out of SharePoint isn't proving nearly as hard as putting information into DNN/EVOQ.  You see the web-based CMS's are designed for you to do everything through the browser and I'm trying to script and code.  Just not what they were made for.

So here is where I have been and where I might go.

1. Export from SharePoint and "call" the "create page" from the DNN/EVOQ API to create the pages...  this failed because it's very difficult because it's not just one API call to create a page and it's not documented AT ALL.
   
2. Export from SharePoint and "insert" into the database directly for DNN/EVOQ.  I'm a database guy so this should have been easy.  Problem is the database seems to be uber-normalized and a single change can sometimes need multiple rounds trips to the same table. So doing it reliably without wrecking the whole system is very tricky
   
3. Export from SharePoint and "create" a "Export" package that DNN/EVOQ can process using their own "Import" wizard to bring in just pages and content.  so far this looks like the most bulletproof method and I'm making baby steps toward it.  I've got the actual file that holds all the "page" info and am just running into trouble with DNN/EVOQ parsing it during the "import" pre-check.
   
4. This may be where I end up, I just found a project that utilizes the new DNNPrompt API.  This API actually has a command called "New Page" and can be called from powershell.  I know that the #3 solution will probably lead to further enhancement and give me more options, but this powershell route MAY be a stopgap to just get going.  If I can't get the parsing of my package to work then this may be where I end up

So the journey continues and should I figure out a path I will be posting my solution so hopefully it will help others regardless of if you're moving toward DNN or Evoq we all need a way to bring in our data and not all of us are blessed with small sites that manual effort is enough.

Let me know your thoughts and if you've come up against this before. Looking forward to hearing your horror and success stories with migrations large and small.

Google translate the monkey executives can't get off their back

Often times we are asked about "translation" or someone just says outright, "put google translate on my site".  They'll even go so far as to reference a law that says they need it in order to comply.  The truth is "translation" isn't about a technology or piece of software, but rather similar to accessibility it's about a set of best-practices and recommended features for your site.  

Certainly as a developer it's much easier to put a few lines of JavaScript into a theme file or include it in the header and just check off the "translation" checkbox, but are we really meeting the goal?

I think it's too much time under the business analyst hat that has me always looking deeper into not only the headline of requirements but why they exist at all.  So when someone tells me they "have" to have their site translated I push back and ask "why". Then when they reference a law or a statute or a policy, i read it and actually ask them if translating the website alone will mean compliance.

Take for example this sentence from a document a user recently brought to my attention...

From: Code of Federal Regulations (Title 29 Part 38)

Excerpt: A recipient should ensure that every program delivery avenue (e.g. electronic, in person, telephonic) conveys in the appropriate languages how an individual may effectively learn about, participate in, and/or access and aid, benefit, service, or training that the recipient provides.

Now if you read that sentence you'll see that translating the website is only a very small portion, in fact it's only a small portion of "electronic". You see because, and I'll use the google widget as an example, these "silver bullet" widgets only translate the visible HTML it means they miss any text "burned in" on images. It also won't cover any PDFs or office documents someone may download.  Let alone emails you may try to exchange with a potential "aid recipient".

Now take into account the fact that your call center and walk-up services also either must have access to or be trained in interpreting and you've now got a picture of what following the true spirit of the law means.  Think of it this way, how well will your baseball be in the field if you only man first base and the pitchers mound and leave all the other positions empty?

Now for those who need further proof to demonstrate that there is no "magic pill" that solves the issue and in fact they can make things worse by trying to have an automated system translate "meaning" and "intent" here are a couple links from federal sites which cover the topic very well and should hold weight with management, at least more so than the blog ramblings of a developer.

 

Lost in Translation - A quick piece about how automated translation is seen as a "silver bullet" but really the problem is much larger.

https://digital.gov/2012/10/01/automated-translation-good-solution-or-not/

 

Dept. of Labor (Machine Translation) slide deck: a comprehensive look at the pitfalls of automated translation and a set of best practices and suggested approved alternatives and additives to automated translations.

https://www.dol.gov/sites/dolgov/files/OASAM/legacy/files/062414Machine_TranslationWebinar.pdf

Of course, I'm always interested in your views on it and your experiences in handling this request.  Please comment and let me know your story and how it went.