Dynamics NAV Upgrades: Best Practices

Transcription

1 Dynamics NAV Upgrades: Best Practices

2 Today s Speakers David 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 Long Has 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 Traxinger Has been working with Microsoft Dynamics NAV since 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.

3 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

4 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?

5 Key Factors to Consider for Upgrades ISV 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?

6 Key Factors to Consider for Upgrades Database 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 tables o SQL scripts to remove large quantities of non-critical data

7 Pre-Upgrade Prep and Estimation Process Begin 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?

8 Pre-Upgrade Prep and Estimation Process Further 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.

9 Pre-Upgrade Prep and Estimation Process Pull 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.

10 Deciding What Customizations to Bring Forward Decision: 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

11 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.

12 Don t Add Too Much to Upgrade Always 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

13 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

14 Data Migration Hardware 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

15 Data Migration Updated 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

16 Data Migration How to Handle Custom Fields in Upgrade with More Than 1 Jump in NAV Version? Field checker process Plateau version Temp tables

17 Extensions and the Future of NAV Upgrades What to expect as issues. Converting from on-prem solution to extension solution. o Issues with data migration o Issues with updating the extensions if any bug fixes o 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

18 Four Phases of an Upgrade

19 Overall Upgrade Project Flow

20 Phase 1 Object Merge 2 3 Weeks

21 Merge Phase Merge Automatic (65%) Refactor - Human Interaction (30%) Re-Write Full Cycle Development (5%)

22 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.

23 Object Delta with Multiple Add-Ons

24 Object Merging Merge Plan The Order of the Merge Plan is Dictated by the Size of the Delta Start with the largest Delta

25 Phase 2 Data Migration 2 to 4 Weeks

26 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

27 Phase 3 Testing 1 to 3 Months

28 Testing Upgrade Best Practice I. Test In-House First Functional Consultant Testing Setup Data Report Selections External Applications in TEST Mode Document All Changes for Go-Live

29 Testing Upgrade Best Practice II. Customer Testing Common Misconceptions about Testing 1. 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

30 Testing Upgrade Best Practice II. Customer Testing Common Misconceptions about Testing 2. 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!

31 Testing Upgrade Best Practice II. Customer Testing Common Misconceptions about Testing 3. 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

32 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

33 Profile Configurations In 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

34

35 Testing Upgrade Best Practices II. Customer Testing Reluctance to Testing 1. Sometimes Don t Know How (They re Not IT Professionals) 2. Help Them Understand the Testing Process 3. Test Guide 7 pages Non-Technical Defines Successful Testing Importance of Variety in Test Data The Basics of Testing - and - Resolution Re-Testing

36 Testing Upgrade Best Practices III. Successful Testing brings Issues for Resolution Established Communication Path 1. Get on the Phone with the User If Needed Do a Screen Share Debug as they reenact the issue

37 Testing Upgrade Best Practices III. Successful Testing brings Issues for Resolution Established Communication Path 2. Rally - Online Agile Project Management Platform Work Tickets Initiated by the User Can Upload Reports/Screenshots to Describe the Issue ed When Ticket Is Entered Fast Turn-Around on Requests to not Delay Testing

38 Testing Upgrade Best Practices III. ISSUES FOUND IN TESTING Resolving Code Issues 1. Developers Skilled in All Versions of NAV Code 2. Developers Skilled in ISV Product Code 3. Knowledgebase of Hotfixes and Routine Customizations

39 Testing Upgrade Best Practices III. DON T LEAVE TESTING TO CHANCE Testing Activity Tool 1. Reports and Pages Ran 2. Determine Areas Not Tested 3. Forecast End of Testing Phase 4. Forecast Our Workload 5. Aid in Suggesting a Go-Live Date

40 When is Testing Done? Testing is never done. But, when it s done enough, we Go Live.

41 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

42 Go Live and Post Go Live Support - 1 Month

43 Why Upgrade? What s New

44 Performance Client Performance Network Performance SQL Performance

45 Events Old Way: Modify the base object

46 Events New Way: A custom object that hooks into an Event in a base object

47 Workflows Connect business process steps performed by different users

48 Data Exchange Framework Common definitions and mappings for integrations

49 BI and Reporting Moving beyond black and white reports

50 Instantly send communications using customizable templates

51 Client Options Work from any device windows, web, phone, or tablet

52 Preview Posting See the impact of your posting before your ledgers are updated

53 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

54 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

55 Q & A

56 Thank You!