how to Upgrade MOSS 2007 to MOSS 2010

Hi, you can start from here http://technet.microsoft.com/en-us/sharepoint/ee517214.aspx

Woah, that's a big question you are asking there! I'm afraid you can't really expect someone to give an in-depth answer to this one given that there is so much involved in planning and testing. There are some key decisions to be made around the upgrade method (in-place, DB attach or a hybrid approach), hardware requirements (SharePoint 2010 is 64-bit only) and visual upgrade. I highly recommend checking out either Professional SharePoint 2010 Administration or SharePoint 2010: Best Practices for Upgrading and Migrating by Joel Oleson. FYI, there is no "MOSS 2010" - MS have dropped the Office terminology for SharePoint 2010 indicating they feel it is a strong enough product to stand alone. Similarly, WSS v4 is now known as SharePoint Foundation. HTH.Benjamin Athawes Twitter SharePoint Blog

first i have use microsoft note .. and we have that using test environment then check all ur issue and link size, users , DB, custom, Design, 3rd party tool , workfow, downtime. all we caonsider then we can try test run first again and agina and then less issue ... following the steps we have considering the best .. Make your test environment as similar as possible to your real environment. If possible, use the same kind of hardware and configure it by using the same settings, the same URLs, and so on. The more you can minimize the differences between your test environment and your real environment, the better. The more differences you introduce, the more time that you are likely to spend time tracking down unrelated issues to make sure that they will not occur during the actual upgrade.Know what is in your environment. Do a full survey first. Take the time to document the hardware and software that is present in your environment, what server-side customizations are installed and used, and where, and what settings you need.Use real data. Use copies of your actual databases to run the tests. When you test by using real data, you can identify any trouble areas and also determine your upgrade performance. It also gives you the opportunity to measure how long different upgrade sequences and actions take on different kinds of data. If you cannot test all the data, test a representative subset of the data to make sure that you have uncovered any issues with the different kinds and sizes of sites, lists, libraries, and customizations that are present in your environment.Run multiple tests. A single test can tell you whether you will encounter big problems, but multiple tests will help ensure that you have uncovered all the issues that you might face and can also give you a more accurate timeline for the process. By running multiple tests, you can determine which upgrade approaches will work best for your environment, which downtime mitigation techniques you should plan to use, and how the process or performance may change after you address the issues that you uncovered in your first tests. Your final test pass can help you validate whether you have addressed all of the errors and are ready to upgrade your production environment.Do not ignore warnings. Even though it is not an error, a warning can lead to problems later in the upgrade process. Work through errors; yes, but also investigate any warnings to make sure that you know what the effect of that warning might be.Test the upgraded environment, not just the upgrade process. Check your service applications and services. Run a search crawl and review the log files. Verify that My Sites is working.Verify sites in both Visual Upgrade modes. Do not assume that because the site can be previewed well in one mode that it will work correctly in the other mode. Check both the previous version and new version user experience.Consider a preview environment. You can create a preview environment in which your users can verify their sites after a test upgrade, so that they can help you verify the upgrade and find issues. You can use a read-only environment, or you can let your users make changes but warn them that any changes they make will not be saved. Consider limiting this preview environment to a small set of representative sites, and limiting access to interested parties only, to reduce the time that you will need to host the preview environment and the amount of feedback you receive. Estimate content database storage The following process describes how to approximately estimate the storage required for content databases, without considering log files: Calculate the expected number of documents. This value is referred to as D in the formula. How you calculate the number of documents will be determined by the features that you are using. For example, for My Sites or collaboration sites, we recommend that you calculate the expected number of documents per user and multiply by the number of users. For records management or content publishing sites, you may calculate the number of documents that are managed and generated by a process. If you are migrating from a current system, it may be easier to extrapolate your current growth rate and usage. If you are creating a new system, review your existing file shares or other repositories and estimate based on that usage rate. Estimate the average size of the documents that you will be storing. This value is referred to as S in the formula. It may be worthwhile to estimate averages for different types or groups of sites. The average file size for My Sites, media repositories, and different department portals can vary significantly. Estimate the number of list items in the environment. This value is referred to as L in the formula. List items are more difficult to estimate than documents. We generally use an estimate of three times the number of documents (D), but this will vary based on how you expect to use your sites. Determine the approximate number of versions. Estimate the average number of versions any document in a library will have (this value will usually be much lower than the maximum allowed number of versions). This value is referred to as V in the formula. The value of V must be above zero. Use the following formula to estimate the size of your content databases: Database size = ((D V) S) + (10 KB (L + (V D))) The value of 10 KB in the formula is a constant that roughly estimates the amount of metadata required by SharePoint Server 2010. If your system requires significant use of metadata, you may want to increase this constant. As an example, if you were to use the formula to estimate the amount of storage space required for the data files for a content database in a collaboration environment with the following characteristics, you would need approximately 105 GB. Input Value Number of documents (D) 200,000 Calculated by assuming 10,000 users times 20 documents Average size of documents (S) 250 KB List items (L) 600,000 Number of non-current versions (V) 2 Assuming that the maximum versions allowed is 10 Database size = (((200,000 x 2)) 250) + ((10 KB (600,000 + (200,000 x 2))) = 110,000,000 KB or 105 GB Features that influence the size of content databases The use of the following SharePoint Server 2010 features can significantly affect the size of content databases: Recycle bins Until a document is fully deleted from both the first stage and second stage recycle bin, it occupies space in a content database. Calculate how many documents are deleted each month to determine the effect of recycle bins on the size of content databases. For more information, see Configure Recycle Bin settings (SharePoint Server 2010).Auditing Audit data can quickly compound and use large amounts of space in a content database, especially if view auditing is turned on. Rather than letting audit data grow without restraint, we recommend that you only enable auditing on the events that are important to meet regulatory needs or internal controls. Use the following guidelines to estimate the space you will need to reserve for auditing data: Estimate the number of new auditing entries for a site, and multiply this number by 2 KB (entries generally are limited to 4 KB, with an average size of about 1 KB). Based on the space that you want to allocate, determine the number of days of audit logs you want to keep. Office Web Apps. If Office Web Apps are being used, the Office Web Apps cache can significantly affect the size of a content database. By default, the Office Web Apps cache is configured to be 100 GB. For more information about the size of the Office Web Apps cache, see Manage the Office Web Apps cache. Deepesh Yevle MCTS