dynamics nav upgrades: best practices · 2019-12-16 · has been working with microsoft dynamics...
TRANSCRIPT
Dynamics NAV Upgrades: Best Practices
Today’s SpeakersDavid Kaupp
Began working on Dynamics NAV in 2005 as a software developer and immediately gravitated to upgrade practices and procedures. He has established himself as an expert in this area and has been a technical lead in the upgrade area for the duration of his NAV career.
Jon LongHas an established track record of success in transitioning complex client ERP systems from old to new technology. With a background in manufacturing and distribution as a business owner, Jon was naturally inclined to learn – and subsequently become an expert in – business software development using the latest languages. Since 2002 Jon has focused specifically on NAV and earned certifications from some of the best NAV experts in the industry.
Matt TraxingerHas been working with Microsoft Dynamics NAV since 2006. During those years he has worked as a developer, consultant, project manager, and support person. He has had the privilege to see NAV from many different views because of his experience working for companies that develop add-on products, traditional partners, and directly for end-users.
Agenda: Upgrade Best Practices/Key Factors• Key Factors to Consider for Upgrades• Pre-upgrade Prep / Estimation Process• How To Decide What Customs to Bring Forward• Discuss How to Keep from Adding New "Development" During an Upgrade• Data Migration• Future Of NAV: Events And Extensions• Four Phases of an Upgrade • Various Menu / NAV Pane Versions (Old Pre-Nav4 Menus, Classic NAV
Pane, RTC NAV Pane)• Q&A w/ Audience
Key Factors to Consider for Upgrades Custom Code
Decide with the client what % of customs that are needed (an assessment) to determine the route below:
• What is an appropriate balance between % of custom code and research?
• Carry forward with an upgrade?
• Remove customs?
• Refactor customs into Events?
Key Factors to Consider for UpgradesISV Add-Ons
• Are all add-ons active or non-existent anymore?o If they are non-existent, do they have replacement add-ons?
• Are the ISV add-ons in “restricted” object ranges (i.e. 37x million) and can they be upgraded still?
• Are there any add-on solutions that are available to eliminate customs?
Key Factors to Consider for UpgradesDatabase Size
• Key issues with upgrades can be related to DB size.o Database sizes larger than 100 GB need to be addressed to see what
can be done to keep the data migration at GoLive within a 2 day weekend window.
• Key ways to address database size and long runtimes:o Dimension caching:
Cut migration times down several hours up to several days (90% of runtime down to less than 1%).
45% of DB size in old DB’s w/ Dimensions, converts down to less than 1% in the new converted DB.
o “Date filtering” of posted document tableso SQL scripts to remove large quantities of “non-critical” data
Pre-Upgrade Prep and Estimation ProcessBegin with a Mindmap Survey
• Client needs? Why upgrade? We need to “know” about the db so that we’ll scope the upgrade correctly. The client wants us to know them accurately.
• Add-ons?o Including any discontinued add-ons or ones that are replaced by NAV base.o Does the vendor have a good track record of support for their add-ons?o Would they like to add any new add-ons?
• Version of NAV (from/to)?
• DB size? How many companies?
• Current / future hardware?
Pre-Upgrade Prep and Estimation ProcessFurther Data Gathering (DB and Objects)
• We always pull all modified & custom objects for NAV base and add-ons which helps scope the size of the object merge component of the upgrade.
• Table Information: what data the client is using in custom and add-on tables.
• Custom Field Checker tool to check for certain table fields with data.
• Report Logging tool: identify reports being used.
• Dataport logging with small a code change.
Pre-Upgrade Prep and Estimation ProcessPull Together into a Consolidated Analysis Document
• Technical and Sales document.
• Auto-calculates: raw data and addl factors, gives us total # of hours and dollars with different resource rates for the project.
• Technical write-up for the development team, but also feeds into our final SOW process for Sales.
Deciding What Customizations to Bring ForwardDecision: Bring “Some” Customizations Forward During the Upgrade?
• Balancing act between research on all of the customs and how long it actually takes to merge everything forward.
• Usually stick w/ a 5% or less to help a client decide if it’s worth the extra research to eliminate code debt.o i.e., 100 hrs of all research vs. extra 30 hrs to bring those customs forward in
upgrade.
• Report logging tool: eliminate the most expensive NAV objects to convert.
• Dataport logging
Deciding What Customizations to Bring Forward• Proprietary Field Checker tool
o Report spits out all custom fields (or fields in a particular range) and check if they have data in them (with counts).
o Decide on key areas of customization.o A general rule can be used that if they decide to eliminate all custom fields,
then it’s likely that they can eliminate the custom code in the same objects.
• Using the Field Checker tool, and Report Logging helps the client decide on the low hanging fruit which customs to bring forward without a lot of extra research.
• Using Object Manager Advanced for “Where-Used” scans.
Don’t Add Too Much to UpgradeAlways a balancing act to allow the client to continue to use and update their current NAV dB while we are upgrading
•Object sync-up points•Parallel development•Add/remove whole add-ons •Parallel projects can kill an upgrade cycle
Don’t Add Too Much to Upgrade
• Code freeze is best
• Client technical staff > perform development simultaneously in both current and upgrade dBs.
• Timeline object sync-ups with PROD & UPGRADE db in TEST.o Additional concurrent development will incur additional time and cost.
• DEV and TEST (QA) environments
Data MigrationHardware Plays a Vital Role in Upgrade Performance, Esp. for Larger Databases: Critical for Golive Weekend
• SSD drives • Sufficient memory, and CPU speed • Faster the hard drives RPM’s• Enough disk space allocated • 5x-10x the storage space
Data MigrationUpdated Microsoft QuickGuide /Instructions
• QuickGuide as the base• Revise it for each upgrade client specific • Time metrics • Common steps that we replicate • Alternate resource• Merged migration toolkits
Data MigrationHow to Handle Custom Fields in Upgrade with More Than 1 Jump in NAV Version?
• Field checker process• Plateau version• Temp tables
Extensions and the Future of NAV Upgrades
• What to expect as issues.
• Converting from on-prem solution to extension solution.o Issues with data migrationo Issues with updating the extensions if any bug fixeso Ability to customize the add-on extension solution
• Is it worthwhile to convert a customer from traditional solution to extension solution?
• What types of customs are good extension candidates?o Pages, published events
Four Phases of an Upgrade
Overall Upgrade Project Flow
Phase 1 Object Merge 2 – 3 Weeks
Merge Phase• Merge – Automatic (65%)
• Refactor - Human Interaction (30%)
• Re-Write – Full Cycle Development (5%)
Object Delta – Focus Merge Effort on Delta Only
Define Delta vs base NAV for each add-on plus the client customizations. You will always do this to build the old Base and new base.
Object Delta with Multiple Add-Ons
Object Merging – Merge PlanThe Order of the Merge Plan is Dictated by the Size of the Delta
Start with the largest Delta
Phase 2 Data Migration – 2 to 4 Weeks
Data Migration Best Practice• The Migration Runtime Should Fit In A 2 Day Weekend• Ram And Disk Requirements For Migrations vs Production• Overcoming Long Running Migrations• Modify Migration Code To Accommodate Multiple Companies
Phase 3 Testing – 1 to 3 Months
Testing – Upgrade Best PracticeI. Test In-House First
Functional Consultant Testing• Setup Data• Report Selections• External Applications in TEST Mode• Document All Changes for Go-Live
Testing – Upgrade Best PracticeII. Customer Testing
Common Misconceptions about Testing1. The Code has Already Been Tested
• Developer Testing: Ensures the object compiles and runs• User Testing: Ensures the business process expectations are met.• New NAV + ISV Add-Ons + Customizations <> Code Compatibility
Testing – Upgrade Best PracticeII. Customer Testing
Common Misconceptions about Testing2. Only the ERP Application is Changing – Everything Else Remains the Same
• Introduce new NAV Functionality• Discover and Implement new NAV functionality!• Positive Pay, Report Scheduling from PRINT button,
Workflows….• “Pocket Systems” – Seek and Destroy!
Testing – Upgrade Best PracticeII. Customer Testing
Common Misconceptions about Testing3. Testing is Only For Department Heads – Not All Users
• Saturate the Users in the New Version• Allow them to get Comfortable with it• User Testing increases Quality
Role Centers and Testing• Role Center Customizations are typically Profile
Configurations
• Profile Configurations are like Personalizations but on a group level
• Personalizations are like Customizations, but an end user task
• Extensive Configurations Can Add To Scope Creep
Profile ConfigurationsIn a Classic to RTC Upgrade
• Profile Configurations do not exist in Production• Menu’s are replaced by Profile Configurations and the “Directory”• Can’t transfer from Test to Prod at GoLive without trickery• Extensive Profile Configurations may cause scope creep
In an RTC to RTC Upgrade• Profile Configurations may already exist• Extensive Profile Configurations in Production during an upgrade will
over-write any that are performed in the Test DB.• Extensive Profile Configurations may cause scope creep
Testing – Upgrade Best PracticesII. Customer Testing
Reluctance to Testing1. Sometimes Don’t Know How (They’re Not IT Professionals)2. Help Them Understand the Testing Process3. Test Guide – 7 pages – Non-Technical
• Defines Successful Testing
• Importance of Variety in Test Data• The Basics of Testing - and - Resolution Re-Testing
Testing – Upgrade Best PracticesIII. Successful Testing brings Issues for Resolution
Established Communication Path1. Get on the Phone with the User If Needed
• Do a Screen Share• Debug as they reenact the issue
Testing – Upgrade Best PracticesIII. Successful Testing brings Issues for Resolution
Established Communication Path2. Rally - Online Agile Project Management Platform
• Work Tickets Initiated by the User• Can Upload Reports/Screenshots to Describe the Issue• E-Mailed When Ticket Is Entered• Fast Turn-Around on Requests to not Delay Testing
Testing – Upgrade Best PracticesIII. ISSUES FOUND IN TESTING
Resolving Code Issues1. Developers Skilled in All Versions of NAV Code2. Developers Skilled in ISV Product Code3. Knowledgebase of Hotfixes and Routine
Customizations
Testing – Upgrade Best PracticesIII. DON’T LEAVE TESTING TO CHANCE
Testing Activity Tool1. Reports and Pages Ran2. Determine Areas Not Tested3. Forecast End of Testing Phase4. Forecast Our Workload5. Aid in Suggesting a Go-Live Date
When is Testing Done?
Testing is never done.
But, when it’s done enough, we Go Live.
Data Migration at Go-Live Best Practice• Avoid Weekends Involving Holidays During A Go-live
Migration• Schedule Backup Resources Especially For Upgrades That
Span Multiple Days• Failure Is Not An Option• Plan For The Best, Prepare For The Worst• Ensure 24 Hour Uptime On Server• Turn Off All Background Services (VM’s And Sql Backups,
Windows Updates Etc...)• Minimize Variables To Simplify All The Complexity Of A Go-live
Go Live and Post Go Live Support - 1 Month
Why Upgrade?
What’s New…
Performance• Client Performance• Network Performance• SQL Performance
EventsOld Way: Modify the base object
EventsNew Way: A custom object that hooks into an Event in a base object
WorkflowsConnect business process steps performed by different users
Data Exchange FrameworkCommon definitions and mappings for integrations
BI and ReportingMoving beyond black and white reports
EmailInstantly send communications using customizable templates
Client OptionsWork from any device windows, web, phone, or tablet
Preview PostingSee the impact of your posting before your ledgers are updated
Why Get Into a Pattern of Upgrades?
Microsoft’s Commitment To release a new version of NAV annually To release monthly cumulative updates (CU’s) – often include new
functionality To provide enhanced functionality and technologies
Your Benefits Streamlining operations by taking advantage of all that NAV offers Enabling platform and performance improvements Staying compliant with Microsoft support Getting more value from your Microsoft annual enhancement investment
Why Get Into a Pattern of Upgrades?Your Investment Spread out the NAV upgrade investment to better manage your cost of money Simplify budgeting with fixed fee monthly pricing
Minimize Disruption to Organization Once on RTC (NAV 2013 R2 or Higher) Users already acclimated to new NAV RTC Navigation means less training 3-Tier platform already established No more Report conversions No more Dataport to XML Port conversions No more Form to Page conversions‡ Move to “Events” and experience even greater upgrade efficiency
Q & A
