I have to migrate a document library from sharepoint 2010 to sharepoint 2013 without using any 3rd party tool. any nice approach to achieve it?


Question: Control Fields vs Heap "Mock" Fields for Branching Trigger Behavior
Answer: At the outset, the way I look at it, the first line of the question is a bit of an apples with oranges comparison, i.e. use of Control Fields in a Workflow - Trigger distributed situation Vs in a Trigger only scenario.

Analysing this problem in parts may help answer each of the two facets, one at a time.

One - the interplay of Workflows and Triggers to implement Business Logic. It is up for debate how logic should be distributed, if not all of it can be accomplished in a trigger. Should workflows be used to implement as much is feasible, and only the absolute can't do's must live in a trigger. In my opinion yes, unless the resulting complexity is insanely great. Using declarative features provisioned by the platform allows for taking advantage of any of the forthcoming features of the platform, for eg. cross object workflows precluded the needs for at least some of those early-days cross object triggers.

If you need to straddle logic across workflows and triggers, the 'heap' is the database, and control fields end up becoming the 'static' heap variables.

This is the only situation in which, in my opinion, control fields may be advocated.

The other facet is the use cases for use of control fields - If the resulting complexity of a distributed operation is too great, or if all of it can only be implemented in a trigger, than static 'heap' variables make the most sense, I can't see the needs for any entity specific control variables, although there may be a limited case for User level control fields, particularly in cases, where doing so may prove more efficient to streamline data integration / migration processes.

Immediate Implications

Just talking a little bit about your other question that led to this thread, you are looking at the use of Control Field to distribute logic between a trigger and a workflow vs customising the input using Visualforce, so you can clearly demarcate the source of the change.

Going down a VisualForce route (which I have done for cases like OpportunityContactRoles, where triggers / workflows are not possible) means investing in a test class besides the cost of maintainability and the danger of subverting any new features that become available in out of the box page layouts, eg. inline editing that came to PageLayouts, and it was some time, before that became available in Visualforce. Declarative should always be the preferable approach, unless there are really strong motivations for going custom, as more often than not, it ends up being more expensive in the long run (the cost of maintainability, test classes and deployment inclusive)