আপনার স্থানান্তরিত করার পরিকল্পনা করা ডেটা যদি খারাপ হয় তবে আপনি মাইগ্রেশন করেন কিনা তা ঠিক করা দরকার। খারাপ ডেটা = অকেজো ডেটা।
অভিবাসনগুলি ঝুঁকিপূর্ণ, এটি সত্য। তবে প্রতিটি বড় আইটি প্রকল্প। ঝুঁকি হ্রাস করার উপায় রয়েছে এবং মাইগ্রেশনে অবশ্যই তাদের সামনে পরিকল্পনা করা উচিত।
প্রথমত, সিস্টেমে এখনকার মতো ফিরে যাওয়ার আপনার সবসময় একটি উপায় থাকা উচিত। দ্বিতীয় স্থানান্তরগুলি পরীক্ষার সার্ভারগুলিতে করা উচিত যা কেবল স্থানান্তরের জন্য সেট আপ করা হয়। প্রথমে এটি পরীক্ষা করার ক্ষমতা ছাড়াই মাইগ্রেশন করা বোকামি। তৃতীয়, স্থানান্তরের জন্য সমস্ত কোড উত্স নিয়ন্ত্রণে থাকা উচিত।
চতুর্থত, মাইগ্রেশন শুরু করার আগে আপনার প্রয়োজনীয়তা এবং পরীক্ষার পরিকল্পনা দরকার। আপনার জানতে হবে যে আপনার যদি পুরানো সিস্টেমে 1,293,687 টি রেকর্ড থাকে তবে নতুনতে আপনার এটি একই ছিল বা আপনি জানেন যে তারা কোথায় গেছে (সম্ভবত একটি ব্যতিক্রম টেবিলে)। আপনি যদি কোনও অস্বীকৃত স্কিমকে সাধারন করছেন তবে আপনার শুরুর আগে আপনার কয়টি রেকর্ড শেষ হওয়া উচিত এবং তা পরীক্ষা করে দেখার দরকার। আপনার এমন একটি ডকুমেন্টেশন দরকার যা একটি সিস্টেম থেকে অন্য সিস্টেমে ম্যাপিংগুলি নির্দিষ্ট করে। এটি আপনার QA লোকদের ডেটা সঠিক জায়গায় গেছে কিনা তা পরীক্ষা করতে সহায়তা করবে।
বর্তমানের খারাপ ডেটা কীভাবে পরিচালনা করতে হবে তা আপনাকে নির্ধারণ করতে হবে। কী পরিষ্কার করা যেতে পারে, প্রয়োজনীয় ক্ষেত্রের জন্য কী কী প্রয়োজন হতে পারে যা 'অজানা' বলে, কোন ব্যতিক্রম টেবিলের বাইরে ছুঁড়ে ফেলা উচিত, ব্যবহারকারীদের একটি গ্রুপের দ্বারা ম্যানুয়াল হস্তক্ষেপের কী দরকার (এই দুই ব্যক্তি যদি সত্যই ডুপ বা সিদ্ধান্ত নিচ্ছেন) উদাহরণস্বরূপ একই নামে দুটি অনুশীলনে দু'জন ডাক্তার আছেন এবং যদি এটি ডুপ হয় যে দুটি রেকর্ডের পার্থক্য হয় তখন কোন ডেটা বেছে নিতে হয় ইত্যাদি)।
একটি সফল স্থানান্তর চাবি পরিকল্পনা হয়। আমি খুঁজে পেয়েছি যে পরিকল্পনার (যা পরীক্ষার কেসগুলি এবং ইউনিট পরীক্ষা লেখার অন্তর্ভুক্ত) সাধারণত আসল বিকাশের চেয়ে বেশি সময় নেয়।
একটি সফল ডেটা মাইগ্রেশনের পরবর্তী কীটি হল QA। লঞ্চের আগের দিন কিউএ টিমকে ফেলে দেওয়ার কোনও প্রকল্প এটি নয়। কিউএ যখন সমস্যা আছে তখন বলছে এটি লঞ্চ করার কোনও প্রকল্প নয়।
সফল মাইগ্রেশনের আরেকটি চাবিকাঠি হ'ল বেশিরভাগ ডেটা মোতায়েন করা এবং অরজিনাল সিস্টেমটি চলমান অবস্থায় এটি পরীক্ষা করা। আপনি যদি প্রচুর রেকর্ড সরিয়ে থাকেন তবে এটি সময় সাপেক্ষ হতে পারে এবং নতুন পরিবর্তন ঘটতে পারে। সুতরাং আপনার প্রক্রিয়াটি অবশ্যই মাইগ্রেশন শুরু হওয়ার পরে ডেটা পরিবর্তনগুলি টানতে সক্ষম হবে। উদাহরণস্বরূপ এসকিউএল সার্ভারের কিছু পরিবর্তন করুন ডেটা ক্যাপচার বলে যা এতে সাহায্য করতে পারে। আপনি অরগিনাল সিস্টেমের একটি ব্যাকআপ নিতে পারেন এবং একই সাথে ডেটা পরিবর্তন ক্যাপচার চালু করতে পারেন। তারপরে আপনি আপনার মাইগ্রেশন সার্ভারে ব্যাকআপটি পুনরায় তৈরি করতে পারবেন, মাইগ্রেশনটি পরীক্ষা করতে পারবেন, বেশিরভাগ ডেটা লোড হয়ে যাবে এবং তারপরে আপনাকে কেবল পরিবর্তন করা রেকর্ডগুলি লোড করতে হবে। আপনি যখন চূড়ান্ত রেকর্ডগুলি স্থানান্তরিত করবেন, স্থানান্তর না হওয়া পর্যন্ত উত্স সিস্টেমটি বন্ধ করুন turn সময়ের আগে রেকর্ডগুলির সর্বাধিক স্থানান্তরিত করার এটি একটি কারণ, সুতরাং অ্যাপ্লিকেশনটি সর্বনিম্ন সময়ের চেয়ে কম। আপনার মাইগ্রেশনের সময়টি ভালভাবে চয়ন করুন, যেদিন তারা পে-রোল প্রসেস করবেন বা ডাব্লু 2 গুলি প্রেরণ করবেন সেদিন বেতনের সিটেমটি বন্ধ করবেন না। এবং স্বল্প ব্যবহারের সময় এটি করুন। আপনার যদি একাধিক ক্লায়েন্ট থাকে তবে আপনি প্রথমে একজনকে স্থানান্তর করতে এবং অন্যকে করার আগে সব কিছু ঠিক আছে কিনা তা নিশ্চিত করে নিতে পারেন। কোনও সমস্যা থাকলে 10000 এর চেয়ে এক গ্রাহকের ডেটা রোলব্যাক করা অনেক সহজ। তবে আপনি যদি এটি করেন তবে সাবধানতার সাথে পরিকল্পনা করুন। যদি সমস্যা হয় তবে 10000 এর চেয়ে বেশি ডেটা। তবে আপনি যদি এটি করেন তবে সাবধানতার সাথে পরিকল্পনা করুন। যদি সমস্যা হয় তবে 10000 এর চেয়ে বেশি ডেটা। তবে আপনি যদি এটি করেন তবে সাবধানতার সাথে পরিকল্পনা করুন।
যদি মাইগ্রেশনটিতে একটি নতুন ব্যবহারকারী ইন্টারফেস জড়িত থাকে তবে দয়া করে প্রকৃত ব্যবহারকারীগণকে মাইগ্রেশন পরীক্ষার অংশ হিসাবে এটি ব্যবহার করুন। তারপরে আপনি লাইভ হওয়ার আগে অন্যান্য ব্যবহারকারীদের প্রশিক্ষণ দিন (তবে আপনি লাইভ হওয়ার এক সপ্তাহেরও কম সময় আগে তারা ভুলে যাবে)। ব্যবহারকারীদের প্রশিক্ষণের নকশা তৈরিতে সহায়তা করার জন্য জড়িত থাকুন, তারা জানেন যে তাদের কী প্রশ্ন রয়েছে এবং লোকেরা কোন ক্রমে কী জানতে হবে। প্রয়োজনীয় ক্ষেত্র তৈরি করে তাদের ইনপুটটি পান কারণ আপনারা মনে করেন যে ব্যবহারকারীরা রেকর্ডে প্রবেশ করার সময় সাধারণত সেই ডেটা না রাখলে এটি কোনও সাহায্য করা উচিত নয়। তারা কেবল নতুন প্রয়োজনীয় ক্ষেত্রের মধ্যে আবর্জনা ফেলে দেবে কারণ তারা অন্যথায় ডেটা পেতে পারে না।
বর্তমান ডেটাতে কী ভুল আছে তা দেখুন, ভবিষ্যতে খারাপ হওয়া থেকে বাঁচতে আপনি কি বিদেশী কী, সীমাবদ্ধতা, ট্রিগার, ব্যবসায়ের নিয়ম প্রয়োগ, ডিফল্ট মান ইত্যাদির যোগ করতে পারেন? আপনি যখন খারাপ ডেটা সাফ করেন, ভবিষ্যতে সেই একইরকম খারাপ ডেটা এড়াতে আপনার একটি উপায়ও তৈরি করতে হবে। খারাপ ডেটা কেন বরাদ্দ করা হয়েছিল তা বিশ্লেষণ করুন এবং গর্তগুলি ইন্টি নকশা ঠিক করুন।